Second-system effect

{{Short description|Project management and software design pitfall in second major iterations}} {{Distinguish|dual process theory}}

The '''second-system effect''' (also '''second-system syndrome''') is the tendency for a successful first system (often small and relatively elegant) to be followed by a second system that becomes over-engineered or bloated. The effect is commonly attributed to increased confidence after the first success and to accumulated ideas that were deferred from the first system and then added en masse to the second.<ref>{{cite book |last=Brooks |first=Frederick P. Jr. |author-link=Fred Brooks |title=The Mythical Man-Month: Essays on Software Engineering |publisher=Addison-Wesley |year=1975 |chapter=The Second-System Effect}}</ref><ref>{{cite web |last=Raymond |first=Eric S. |author-link=Eric S. Raymond |title=second-system effect |work=The Jargon File |url=https://catb.org/jargon/html/S/second-system-effect.html |access-date=2026-01-26}}</ref>

Fred Brooks introduced the phrase in ''The Mythical Man-Month'' (1975) while describing IBM's transition from relatively simple operating systems for the IBM 700/7000 series to the much more ambitious OS/360 for the IBM System/360 family (announced in 1964).<ref>{{cite book |last=Brooks |first=Frederick P. Jr. |author-link=Fred Brooks |title=The Mythical Man-Month: Essays on Software Engineering |publisher=Addison-Wesley |year=1975 |chapter=The Second-System Effect}}</ref>

== Description == In Brooks's formulation, an architect's first system is often "spare and clean" because the designer is still learning and is cautious about uncertain generalizations. The second system is "the most dangerous" because the designer is more confident and is tempted to incorporate every previously deferred improvement, optional feature, and generalization, resulting in a successor that is harder to build, understand, and evolve.<ref>{{cite web |title=The Mythical Man-Month (PDF) |url=https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf |access-date=2026-01-26}}</ref>

The effect is closely related to feature creep and to design over-generalization, where the second system attempts to anticipate too many future needs at once rather than serving current, validated requirements.<ref>{{cite web |last=Raymond |first=Eric S. |author-link=Eric S. Raymond |title=second-system effect |work=The Jargon File |url=https://catb.org/jargon/html/S/second-system-effect.html |access-date=2026-01-26}}</ref>

== Additional manifestation == Brooks also described a second variant of the effect that is not primarily about adding features: a tendency to refine techniques that have become obsolete because the system's basic assumptions have changed (for example, optimizing around an old hardware or operational model after the environment has shifted). He cited OS/360 as containing many examples of this kind of misapplied refinement.<ref>{{cite web |title=The Mythical Man-Month: The Second-System Effect (excerpt/quotes) |url=https://pages.cs.wisc.edu/~param/quotes/man-month.html |access-date=2026-01-26}}</ref>

== Relation to rewrites, prototypes, and planned replacement == The second-system effect is frequently discussed in the context of major rewrites (a "version 2" or second implementation), but it can occur in any second large-scale system built after an initial success.

In ''The Mythical Man-Month'', Brooks separately argues that teams should often expect to build a pilot (or throwaway) system to learn what is actually needed; the management question is whether to plan for that throwaway in advance or to mistakenly ship it as the final product.<ref>{{cite book |last=Brooks |first=Frederick P. Jr. |author-link=Fred Brooks |title=The Mythical Man-Month: Essays on Software Engineering |publisher=Addison-Wesley |year=1975}}</ref> This view is echoed in later system-design literature: Butler Lampson recommends "plan to throw one away" and notes that if there is anything genuinely new about a system's function, the first implementation will likely need to be redone.<ref>{{cite book |last=Lampson |first=Butler W. |title=Hints for Computer System Design |year=1983 |publisher=IEEE Software |url=https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/acrobat-17.pdf |access-date=2026-01-26}}</ref>

As a result, some teams deliberately schedule a second implementation to remove early mistakes, false generalizations, and exploratory scaffolding from the first iteration. This "planned replacement" approach is sometimes framed as ''sacrificial architecture'': accepting that parts or all of the current architecture will be replaced once the domain is better understood, and designing in ways that make replacement easier when the time comes.<ref>{{cite web |last=Fowler |first=Martin |author-link=Martin Fowler (software engineer) |title=Sacrificial Architecture |date=2014-10-20 |url=https://martinfowler.com/bliki/SacrificialArchitecture.html |website=martinfowler.com |access-date=2026-01-26}}</ref>

A common mitigation is incremental replacement (often described as the "Strangler Fig" approach), where new functionality is built around the legacy system and gradually replaces it, reducing the risk of a single all-at-once second system.<ref>{{cite web |last=Fowler |first=Martin |author-link=Martin Fowler (software engineer) |title=Strangler Fig Application |date=2024-08-22 |url=https://martinfowler.com/bliki/StranglerFigApplication.html |website=martinfowler.com |access-date=2026-01-26}}</ref><ref>{{cite web |title=Strangler application pattern |url=https://microservices.io/patterns/refactoring/strangler-application.html |website=microservices.io |access-date=2026-01-26}}</ref>

== Mitigation == Brooks suggested that avoiding second-system failure requires explicit discipline, including: * resisting "functional ornamentation" and unnecessary generalization, * making resource costs visible for small features (e.g., budgeting memory and performance costs per capability), * ensuring experienced architectural leadership (including architects who have already designed multiple comparable systems).<ref>{{cite web |title=The Mythical Man-Month (PDF) |url=https://web.eecs.umich.edu/~weimerw/2018-481/readings/mythical-man-month.pdf |access-date=2026-01-26}}</ref>

In practice, mitigation strategies often include prioritizing validated requirements, staged delivery, strict scope management, and architectural review processes designed to challenge speculative features.

== See also == {{Portal|Engineering}} * Anti-pattern * Feature creep * Inner-platform effect * Osborne effect * Sophomore slump * Unix philosophy * Big ball of mud * Strangler fig pattern

== References == {{Reflist}}

== External links == * {{cite web |title=Things You Should Never Do, Part I |last1=Spolsky |first1=Joel |author1-link=Joel Spolsky |date=April 6, 2000 |url=https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ |website=Joel on Software |access-date=October 15, 2021}} * {{cite web |title=Notes on Haskell |date=August 21, 2007 |last1=Turoff |first1=Adam |url=https://notes-on-haskell.blogspot.com/2007/08/rewriting-software.html |access-date=October 15, 2021}} * {{cite web |url=https://www.neilgunton.com/doc/?o=1mr&doc_id=8583 |title=Rewrites Considered Harmful? |last1=Gunton |first1=Neil |date=July 20, 2008 |access-date=October 15, 2021}} * {{cite web |url=http://chadfowler.com/2006/12/27/the-big-rewrite.html |title=The Big Rewrite |last1=Fowler |first1=Chad |archive-url=https://web.archive.org/web/20161208161441/http://chadfowler.com/2006/12/27/the-big-rewrite.html |archive-date=December 8, 2016}}

{{Fred Brooks}} Category:Software quality

{{software-eng-stub}}

de:Vom Mythos des Mann-Monats#Das Problem des zweiten Systems