The proposal lands with familiar energy.
The existing system is unmaintainable. The team needs a clean start. The old architecture has too many compromises, too many patches, too many places where nobody knows whether a condition is business logic or a bug preserved for one important customer. The replacement architecture document is already thirty pages long. The diagrams are immaculate. Every bounded context has a name. Every interface has a future. Every awkward production behaviour has been dissolved into a principle.
The room relaxes when the new system is described. That is the first warning sign.
Greenfield work feels good because nothing has contradicted it yet. No customer has used the feature in the wrong order. No old export format has become a contractual obligation. No dependency has timed out under load. No data migration has uncovered a decade of silent inconsistency. No one has asked the new code to support a report invented by a finance team that no longer exists but whose numbers are still used in board papers.
The blank repository is not evidence that the design is better. It is evidence that the design has not been exposed to reality.
This is the greenfield delusion: the belief that the beginning of a software project is where value is created and the later work is merely cleaning up the mess. It flatters engineers because new projects are intellectually fresh. It flatters organisations because new projects are visible, fundable, and easy to announce. It flatters executives because replacement sounds more decisive than maintenance. It flatters everyone who would rather draw the system as it should be than understand why the existing system became what it is.
But most software value does not live in the first commit. It lives in the years after the first release, when the system is adapted, corrected, extended, hardened, explained, integrated, and forced to survive the business it serves. That work is brownfield work. It is slower, less glamorous, more politically exposed, and more valuable than the industry usually admits.
The old system is carrying value
Software maintenance has never been a side quest.
The 1978 Lientz, Swanson, and Tompkins study of application software maintenance is old enough to be treated as folklore, but its core observation remains difficult to ignore. The paper reported that maintenance and enhancement consumed a major portion of system life-cycle resources, with rough estimates of total systems and programming resources ranging as high as 75-80%.1 A 1985 executive guide from the US National Bureau of Standards stated the point in similar operational language: software maintenance represented 60-70% of total software cost, with perfective maintenance comprising about 60% of maintenance costs.2
Those numbers should not be treated as a universal constant. They came from particular eras, organisations, systems, and definitions of maintenance. Modern cloud platforms, packaged services, open-source dependencies, SaaS delivery, and continuous deployment have changed the shape of the work. But the direction is stable enough to matter: software does not become expensive because it is first built. It becomes expensive because it keeps being useful.
That sounds backward only because the industry has trained itself to call the useful years legacy.
Useful software attracts change. Users ask for additions. Regulations shift. Competitors move. Product language changes. Security assumptions expire. Vendors deprecate APIs. Hardware and infrastructure evolve. Data volumes grow. The system becomes embedded in work processes, spreadsheets, integrations, training material, customer contracts, and muscle memory. Every year the code accumulates not just technical decisions, but organisational decisions.
Manny Lehman's 1980 laws of software evolution describe this more rigorously. For software that reflects some external reality, Lehman wrote that a used program must continually change or become progressively less useful; he also described how complexity tends to increase unless work is done to maintain or reduce it.3 That is not a defect in a particular team. It is the normal life of software that matters.
The greenfield delusion misreads this normal life as decay. It looks at a system that has absorbed real business pressure and sees ugliness. Sometimes it is ugliness. Sometimes the system really is poorly factored, badly tested, insecure, or so entangled that every change feels like surgery in the dark. But sometimes what looks like ugliness is accumulated knowledge without a clean narrative.
The special handling in the billing path may exist because one customer pays on a calendar nobody else uses. The strange retry rule may exist because a vendor once sent duplicate webhooks for three weeks. The old data field may remain because downstream reporting quietly depends on it. The branch that looks impossible may encode a court settlement, a tax jurisdiction, a board metric, or a support workaround that nobody remembered to document.
A rewrite does not remove that knowledge. It makes the team rediscover it under deadline.
Brownfield systems are hard to work in because they carry the load of being useful. They contain wrong decisions, but they also contain fought-for correctness. They contain compromises, but they also contain the evidence of what users actually needed once the original theory met production.
The clean system has none of that yet. It is not better. It is merely earlier.
Why greenfield feels faster
New projects are fast in the same way a sketch is fast.
A team can create a repository, choose a framework, draw service boundaries, define a schema, and ship a thin slice quickly because the slice does not yet need to preserve the full business. There are no migrations from old states. There are no historical permissions. There is no backward compatibility. There are no users with half-completed workflows. There are no production dashboards whose definitions came from a previous CEO. There is no support team asking why a customer in a discontinued plan lost an export option that only existed in the old interface.
That early speed is real. It is also incomplete.
Martin Fowler's 2019 essay on internal software quality explains the brownfield cost from inside the developer's day. Most programming work happens in the context of an existing codebase, and internal quality affects how easily developers can understand the system, find where a change belongs, and avoid breaking other things.4 This is why a new codebase can feel liberating. Understanding is cheap when there is little to understand.
The problem is that the greenfield feeling gets mistaken for greenfield economics. A new system has low accidental complexity at the beginning because it has not yet had to serve many accidents. A mature system has more complexity because it has been asked to answer more questions. Some of that complexity is waste. Some of it is the product.
This distinction is often invisible in planning decks. The replacement project compares the current system's full complexity against the new system's proposed simplicity. That is not a fair comparison. The fair comparison is between the current system and the new system after the new system has reproduced the behaviours that matter, migrated the data, supported the edge cases, satisfied the integrations, trained the users, rebuilt the reports, and survived the first year of changes.
That comparison is rarely drawn because it makes the rewrite less emotionally satisfying.
Greenfield projects also create a particular kind of status. They let engineers select tools, establish conventions, design architecture, and make visible decisions. Brownfield work asks engineers to understand, constrain, repair, negotiate, and preserve. The first looks like creation. The second looks like caretaking.
Organisations reinforce that hierarchy. New projects get launches. Maintenance gets tickets. New architecture gets review meetings with senior leadership. Brownfield improvement gets hidden inside delivery. The engineer who designs a new platform is seen as strategic. The engineer who quietly removes the defect class that has burned two teams for a year is seen as useful, if someone remembers to notice.
The incentive is easy to observe without a survey, but the available data points the same way on the size of the maintenance load. SonarSource's 2019 survey of nearly 300 developers reported that respondents spent an average of 12 hours per week on code maintenance, with most respondents spending between 11% and 50% of their time on maintenance tasks.5 That is not a lifecycle-cost study, and it should not be inflated into one. It is a reminder that maintenance is not occasional janitorial work. It is a substantial part of the working week.
The people doing that work are not failing to innovate. They are keeping innovation alive long enough to matter.
The rewrite story is seductive
The rewrite story has a reliable structure.
First, the existing system is declared unmaintainable. Then the replacement is framed as the only serious path. Then the organisation promises that this time the architecture will be clean, the tests will be comprehensive, the dependencies will be modern, and the domain model will finally match reality. The old system will be maintained only while the new system is built. The team will move quickly because it is no longer constrained by legacy decisions.
Then the old system keeps changing.
Customers still need features. Security patches still arrive. Regulatory work still lands. Support still escalates defects. Finance still needs reports. The old system cannot stop being the business merely because the new system has become the plan. The organisation ends up paying two costs: it funds the replacement while continuing to maintain the thing being replaced.
Joel Spolsky's 2000 essay about Netscape remains a canonical warning because it names the knowledge loss directly. He argued that rewriting from scratch throws away bug fixes, real-world usage knowledge, and years of programming work; his example was Netscape's decision to rewrite while its previous major browser release aged in the market.6 Spolsky's essay is polemical, and it should not be turned into an absolute rule. Some systems are genuinely worth replacing. But his central warning is still practical: old code contains information that may not exist anywhere else.
The Netscape timeline is not a simple morality play, but it is still instructive. Mozilla's own history says the Netscape browser suite source code was released and the Mozilla Project formally launched on 31 March 1998.7 Netscape 6 was released on 14 November 2000 as the first Netscape product based on open-source code.8 Mozilla 1.0 followed on 5 June 2002.9 Whatever one thinks of the eventual importance of Mozilla, that timeline shows a replacement effort living through years in which the market did not pause.
That is the part rewrite proposals tend to underprice. The business clock keeps running.
Fred Brooks described the second-system effect in The Mythical Man-Month, first published in 1975.10 The idea is that a designer's second system is especially vulnerable to overdesign, because all the deferred ideas from the first system rush into the new one. Rewrites invite this effect. They are sold as simplification, but they often become the place where every grievance, aspiration, pattern, and future requirement is finally allowed into scope.
The replacement starts as a way to escape complexity and becomes a cleaner way to reproduce it.
This does not happen because the team is foolish. It happens because the rewrite is asked to do too many emotional jobs. It must redeem past decisions, modernise the stack, improve developer happiness, satisfy product ambition, clean up data, reduce operating cost, unblock scale, attract hires, and prove leadership is decisive. A project with that many symbolic obligations cannot stay small.
The old system is blamed for being complex because it carries business history. The new system becomes complex because it carries organisational hope.
Brownfield is not surrender
Defending brownfield work does not mean defending every legacy system.
Some systems should be replaced. A system may depend on unsupported hardware, unsupported libraries, insecure protocols, unavailable expertise, or a vendor whose product is ending. It may be so badly coupled that local improvement is slower and riskier than staged replacement. It may encode a business process the organisation is intentionally retiring. It may impose operating costs that cannot be justified. It may have no realistic path to the reliability, security, or compliance level required.
Brownfield stewardship is not sentimentality. It is evidence-based change.
Michael Feathers' Working Effectively with Legacy Code, published in 2004, is useful because it treats legacy work as an engineering discipline rather than a moral failure. The book is organised around mechanics of safe change: feedback, sensing, separation, and ways to get difficult code under test.11 That framing matters. The old system is not simply a thing to hate or preserve. It is a thing to understand well enough to change safely.
Good brownfield work starts by asking what kind of problem exists. Is the issue code structure, testability, product complexity, data quality, team knowledge, dependency age, deployment risk, operational visibility, or organisational ownership? A rewrite is only one possible answer, and often not the first one.
If the code is hard to change because it lacks tests, a testing strategy may buy more safety than a replacement. If the deployment process is fragile, improving release mechanics may deliver value faster than new architecture. If the domain model is confused, mapping the actual domain and refactoring around stable concepts may beat inventing a fresh model from a meeting-room vocabulary. If a few components create most of the risk, replacing those components may be better than replacing everything.
Martin Fowler's 2004 strangler fig application metaphor exists for this reason. Fowler described gradual replacement around the edges of an old system as an alternative to a cut-over rewrite, emphasising reduced risk, steady value, frequent releases, and the ability to monitor progress more carefully.12 The point is not that every system can be strangled cleanly. The point is that replacement can be evolutionary rather than apocalyptic.
Evolutionary replacement respects a fact that greenfield plans often deny: the running system is the source of truth. Its code may be ugly, its database may be awkward, and its interfaces may be embarrassing, but it is the thing currently satisfying the business. A replacement that ignores it is not starting from zero. It is starting from amnesia.
Brownfield work also builds the engineering judgement that greenfield work can hide. In a new system, a developer can often avoid hard tradeoffs by postponing them. In an existing system, the tradeoffs are already there. The developer must understand why a boundary failed, why a test is hard to write, why a dependency became central, why an object grew too many responsibilities, why one customer flow resists simplification, and why a seemingly obvious change breaks a report.
That knowledge is not glamorous. It is architecture in contact with consequences.
It is also where a team learns restraint. Greenfield design rewards possibility: every pattern can be added, every boundary can be redrawn, every dependency can be chosen for the world the team hopes to inhabit. Brownfield design rewards judgement: what can be improved without breaking trust, what can be simplified without erasing meaning, what should be left alone until the team has better evidence.
That restraint is not timidity. It is respect for the fact that working software has obligations. A production system is not only a codebase. It is part of how customers make decisions, how support explains incidents, how finance closes a month, how operations recover from failure, and how other teams plan their own work. Changing it well requires technical skill and social patience at the same time.
This is why brownfield work should be treated as senior work. It demands the ability to read code, but also the ability to read history. It demands the ability to improve structure, but also the ability to know when a rough edge is actually a product dependency. It demands the confidence to remove, not only the confidence to create.
Maintenance is product work
The greenfield delusion survives because maintenance is badly named.
Maintenance sounds like keeping something static. In software, much maintenance is change. The 1985 guide's breakdown described perfective maintenance, meaning changes, enhancements, and extensions, as about 60% of maintenance costs.2 Lientz and Swanson's work similarly emphasised enhancement and user demands as central maintenance issues.13 A large part of what gets called maintenance is actually product evolution.
This matters because organisations often fund maintenance as if it were mere upkeep. They allocate roadmap capacity to new features and leave brownfield work to the gaps. They treat refactoring as an engineering indulgence, dependency updates as chores, and system simplification as something to be done after delivery. Then they are surprised when delivery slows.
Fowler's internal-quality argument is blunt on this point: low internal quality can look cheaper at first, but it makes later changes slower and more error-prone; high internal quality lowers the cost of future change.4 DORA's 2019 report also connected engineering productivity with reducing technical debt, flexible architecture, usable deployment toolchains, and better information search.14 These are not aesthetic concerns. They are delivery concerns.
The business does not experience internal quality directly. Customers do not care whether a class has a clean name. They care when a change that should take a week takes a quarter. They care when a migration breaks their data. They care when a product cannot adapt to a regulation because the old workflow is too tangled to change. They care when every feature arrives late because the system has become hard to understand.
Maintenance is how the product keeps its promises while changing them.
That makes brownfield work a product investment, not merely an engineering clean-up. Improving a deployment path can make future features safer. Removing a bad abstraction can make product experiments cheaper. Retiring a dead workflow can reduce support load. Moving a fragile integration behind a clearer boundary can reduce incident frequency. Adding tests around a business-critical rule can let the team change pricing without fear.
The trap is that these improvements rarely have the theatrical clarity of a new project. A rewrite can be named, budgeted, staffed, and announced. Brownfield improvement is often a sequence of small changes that only become obvious when they are missing. The organisation notices the rewrite because it is an event. It fails to notice maintenance because good maintenance prevents events.
That invisibility affects careers. Engineers who keep systems healthy often look less heroic than engineers who rescue systems after neglect. Teams that prevent rewrites may look less ambitious than teams that propose them. Managers who fund boring improvement may struggle to tell the story compared with managers who launch a transformation.
The value is real anyway.
An organisation that consistently improves existing systems compounds knowledge. It keeps product behaviour close to implementation. It keeps operational experience inside the team. It turns defects into tests, incidents into design changes, and awkward workflows into clearer boundaries. It learns where the system is genuinely obsolete and where it is merely unloved.
An organisation addicted to greenfield resets compounds amnesia. It throws away context, rediscovers edge cases, pauses product progress, and eventually creates a new legacy system with less history and the same organisational habits.
Earn the clean start
There is a responsible version of a clean start.
It begins by proving that the old system cannot meet the need through incremental change. Not that it is unpleasant. Not that developers dislike it. Not that the framework is unfashionable. Not that a new system would be nicer to design. The case for replacement should identify specific constraints: security support, performance ceilings, regulatory exposure, vendor end-of-life, data model limits, release risk, staffing availability, or product strategy that genuinely cannot be served.
Then it should ask what can be learned before the replacement begins. Which behaviours are contractual? Which reports must match exactly? Which edge cases are still used? Which integrations depend on undocumented semantics? Which defects are known and intentionally tolerated? Which old features can be retired instead of reproduced? Which business process should change rather than be ported?
The clean start should be smaller than the fantasy version. It should not reproduce every historical feature by default. It should not carry every deferred architecture idea. It should not become the place where the team adopts a new stack, a new domain model, a new deployment platform, a new design system, a new analytics model, and a new operating process all at once unless the organisation is honest about the risk it is buying.
Replacement should be staged where possible. Put a new boundary around the old capability. Move one workflow. Migrate one customer segment. Replace one report. Keep the old system running while the new system proves itself in production. Use the running system to discover truth, not as a straw man to be defeated in architecture documents.
Most importantly, treat the new system as tomorrow's brownfield from day one.
Fowler's 2004 note ends with that same practical humility: today's work becomes tomorrow's legacy, so new applications should be designed in ways that make future displacement easier.12 That is the antidote to the greenfield delusion. The goal is not to escape maintenance. The goal is to make future maintenance humane.
The proposal in the conference room may still be right. The old system may genuinely have reached the end of its useful life. A clean start may be the least risky path. But the burden of proof belongs on the rewrite, not on the running system. The running system has already proven one thing: it creates enough value that people are still arguing about it.
That value deserves respect, even when the code does not.
Greenfield projects feel productive because they let a team move before reality pushes back. Brownfield projects feel slower because reality is already in the room. The old system has users, history, data, contracts, bugs, workarounds, incidents, and knowledge. It has survived long enough to become inconvenient.
That inconvenience is not proof that value has moved elsewhere.
The serious engineering work is not choosing between worshipping legacy and burning it down. It is learning which parts of the existing system are debt, which parts are knowledge, which parts are obsolete, and which parts are still the business. Then it is changing the system without destroying the value it already carries.
There is no blank field in software for long. Every successful greenfield becomes brownfield. Every clean architecture becomes a historical artefact. Every elegant design is eventually asked to do something its creators did not imagine.
The question is not how to avoid that fate. The question is whether the organisation will still respect the work after the first release party ends.
That is where the value lives.
Footnotes
-
Lientz, B. P., Swanson, E. B., & Tompkins, G. E. (1978). 'Characteristics of Applications Software Maintenance.' Communications of the ACM. https://doi.org/10.1145/359511.359522 ↩
-
National Bureau of Standards. (1985). 'Executive guide to software maintenance.' NBS Special Publication 500-130. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublication500-130.pdf ↩ ↩2
-
Lehman, M. M. (1980). 'Programs, life cycles, and laws of software evolution.' Proceedings of the IEEE. https://doi.org/10.1109/PROC.1980.11805 ↩
-
Fowler, M. (2019). 'Is High Quality Software Worth the Cost?' Martin Fowler. https://martinfowler.com/articles/is-quality-worth-cost.html ↩ ↩2
-
Sonar. (2019). 'Developers spend 30% of their time on code maintenance: our latest survey results, part 3.' SonarSource. https://www.sonarsource.com/blog/developers-spend-30-of-their-time-on-code-maintenance-our-latest-survey-results-part-3 ↩
-
Spolsky, J. (2000). 'Things You Should Never Do, Part I.' Joel on Software. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ ↩
-
Baker, M. (2018). 'Mozilla Turns Twenty.' Mozilla. https://blog.mozilla.org/en/mozilla/mozilla-turns-twenty/ ↩
-
Mozilla. (2013). 'Milestone: Netscape 6 released based on open source code.' about:community. https://blog.mozilla.org/community/2013/05/06/milestone-netscape-6-released-based-on-open-source-code/ ↩
-
Mozilla. (2002). 'Mozilla.org launches Mozilla 1.0.' Mozilla Press Center. https://blog.mozilla.org/press/2002/06/mozilla-org-launches-mozilla-1-0/ ↩
-
Brooks, F. P. (1975). 'The Mythical Man-Month: Essays on Software Engineering.' Addison-Wesley. https://openlibrary.org/works/OL3510570W/The_Mythical_Man-Month ↩
-
Feathers, M. (2004). 'Working Effectively with Legacy Code.' Pearson. https://www.pearson.com/en-us/subject-catalog/p/working-effectively-with-legacy-code/P200000008984 ↩
-
Fowler, M. (2004). 'Original Strangler Fig Application.' Martin Fowler. https://www.martinfowler.com/bliki/OriginalStranglerFigApplication.html ↩ ↩2
-
McClure, C. L. (1984). 'Annotated bibliography on software maintenance.' National Bureau of Standards. https://www.govinfo.gov/content/pkg/GOVPUB-C13-e645dc747f0f584002c0205c3ec2ff77/pdf/GOVPUB-C13-e645dc747f0f584002c0205c3ec2ff77.pdf ↩
-
Forsgren, N., Humble, J., Kim, G., Kersten, M., & Stahnke, M. (2019). '2019 Accelerate State of DevOps Report.' DORA and Google Cloud. https://research.google/pubs/2019-accelerate-state-of-devops-report/ ↩