Build one to throw away vs Second-system effect: What are differences?
Last updated: December 16, 2022 Read in fullscreen view
Recommended for you
- 01 Aug 2024
The Standish Group report 83.9% of IT projects partially or completely fail 150/1772 - 13 Apr 2024 Lessons on Teamwork and Leadership from Chinese story book "Journey to the West" 41/949
- 02 Nov 2021 What is Terms of Reference (ToR)? 23/1466
- 05 Jul 2020 What is Sustaining Software Engineering? 14/1188
- 03 Apr 2022 Microsoft Solutions Framework (MSF) 12/1157
- 20 Mar 2022 What is a Multi-Model Database? Pros and Cons? 11/1063
- 01 Mar 2023 What is Unit Testing? Pros and cons of Unit Testing? 8/355
- 18 Dec 2023 The Cone of Uncertainty in Scrum & Requirement Definition 8/643
- 18 Oct 2021 Key Elements to Ramping Up a Large Team 7/1108
- 30 Jan 2022 What Does a Sustaining Engineer Do? 7/554
- 31 Dec 2021 What is a Data Pipeline? 4/187
- 20 Jul 2022 Software Myths and Realities 4/797
- 07 Jul 2022 Managing Project Execution Terms 3/379
- 22 Sep 2022 Why is it important to have a “single point of contact (SPoC)” on an IT project? 3/843
- 10 Apr 2024 The Parking Lot Method: Unlocking a Simple Secret to Supercharge Your Productivity 3/403
- 26 Sep 2024 Successful Project Management Techniques You Need to Look Out For 2/368
- 12 Aug 2022 What is End-to-end project management? 2/382
- 14 Jun 2022 Example and Excel template of a RACI chart in Software Development 2/707
- 15 May 2022 20 Common Mistakes Made by New or Inexperienced Project Managers 2/247
- 05 Jun 2023 Fractional, Part-Time (virtual) or Interim CTO: Who Will Cover Your Business Needs? 2/109
- 02 May 2022 What Is RAID in Project Management? (With Pros and Cons) 2/734
- 24 Nov 2023 The project management paradox: Achieving MORE by doing LESS 2/193
- 07 Dec 2023 12 project management myths to avoid 1/167
- 01 Mar 2024 10 Project Management Myths 1/120
- 22 May 2022 What are common mistakes that new or inexperienced managers make? 1/243
- 13 Nov 2021 What Is Bleeding Edge Technology? Are bleeding edge technologies cheaper? 1/454
- 25 Apr 2021 What is outstaffing? 1/229
- 27 Jan 2020 Should a project manager push developers to work more hours due to mistakes of manager schedule setting? 1/412
- 17 Oct 2021 Does Fast Tracking increase project cost? /348
- 13 Jan 2020 Quiz: Test your understanding project cost management /568
- 02 Dec 2021 3 Ways to Avoid Scope Creep in IT Consulting /192
- 03 Jul 2022 What is the difference between Project Proposal and Software Requirements Specification (SRS) in software engineering? /955
- 10 Apr 2022 What is predictive analytics? Why it matters? /167
- 06 Jun 2022 Change Management at the Project Level /292
- 10 May 2022 Levels of Teamwork /180
- 03 Jan 2023 Organizing your agile teams? Think about M.A.T (Mastery, Autonomy, Purpose) /333
- 01 Aug 2022 Is planning "set it and forget it" or "set it and check it"? /264
- 23 Jun 2024 Best Practices for Managing Project Escalations /183
- 21 Jun 2024 Dead Horses and the Escalation of Commitment /123
- 30 Nov 2023 Project Managers, Focus on Outcomes — Not Deliverables /143
- 02 Nov 2022 Difference between Change Management and Project Management /216
- 02 Jun 2024 Reviving Ancient Wisdom: The Spiritual Side of Project Management /204
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.
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News