On one hand there is an advice that says "Build one to throw away". Only after finishing a software system and seeing the end product do we realize what went wrong in the design phase and understand how we should have really done it.

On the other hand there is the "second-system effect" which says that the second system of the same kind that is designed is usually worse than the first one; there are many features that did not fit in the first project and were pushed into the second version usually leading to overly complex and overly engineered.

Isn't there some contradiction between these principles? What is the correct view over the problems and where is the border between these two?

The second-system effect

The second-system effect or second-system syndrome is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.

The phrase was first used by Fred Brooks in his book The Mythical Man-Month, first published in 1975. It described the jump from a set of simple operating systems on the IBM 700/7000 series to OS/360 on the 360 series, which happened in 1964.

In The Mythical Man Month Fred Brooks discusses the idea of The Second System Effect. The Second System Effect is the tendency for a project manager or software architect to err on the side of overembellishment when planning their second project. In large part, this is due to the fact that the architect has to exercise a great deal of willpower during the first project by keeping scope under control while constantly thinking about all of the really great things they want to add to the next project.

As an architect, your early projects will be like quicksand. They will pull at you in ways that you haven't experienced before and it is important to have an anchor that can keep you grounded and on track. This is why it is imperative that you seek out the mentorship of someone more experienced and smarter than you to help guide you through your early projects. A good project mentor will provide a safe place for you to express your thoughts and ideas about a project and they will give you honest, candid, and sometimes difficult feedback.

Build one to throw away

"Build one to throw away" means you're building the same "system" again, but with more specific requirements based on what you learned. Second system effect is building a bigger system with broader and vaguer requirements.

(Also, Brooks later said: "This I now perceive to be wrong, not because it is too radical, but because it is too simplistic. The biggest mistake in the 'Build one to throw away' concept is that it implicitly assumes the classical sequential or waterfall model of software construction." He wrote a later book, The Design of Design, encouraging iterative development.)

Most software projects inadvertently plan to build a throwaway product for delivery to customers, instead of heeding Fred Brooks:

In most projects, the first system built is barely usable…

Plan one to throw away; you will, anyhow.

Sometimes, the way to be most effective is to be somewhat inefficient.

Building one to throw away is too often used as an excuse for not doing the job properly. That means that you don't actually encounter enough of the issues in the process to learn enough to make it a good use of anyone's time. And doing it properly, only to throw it away, is even more wasteful.

Once you’ve gotten your users to the point that they can point at a piece of working software and say, “Yes – build me that”, then you can go about building it the right way on top of your production platform.

Let me go a step further, just to be crystal clear.

Do not unit-test that code. Do not use TDD, DDD, CQRS, Event Sourcing, SOA, etc.

Just get it done.

"Build one to throw away" comes from "not knowing what you don't know" at the start, so you learn as you go what you should have done at the start.

Second System Effect comes from "now knowing what you did not know, however not knowing what you still don't know" i.e. Second system effect comes from trying to build a bigger, shinier, more complex system than the first one, without the knowledge needed at the start - sounds a lot like what happens with the first system.

Therefore the second system effect is not a contradiction. Building a second system to the same functionality as the first is never done. The second system always has to be "better", therefore more complex, therefore substantially similar problems to the first system are expected - that should be thrown away.

So build one to throw away, throw it away and build it again with no scope enlargement, and you won't have a second system problem.