The Greenfield Myth: Why Your New Service Is Already Legacy Code

It was 2:15 on a Wednesday when the tech lead pulled up the architecture diagram for the new service. The whiteboard markers were fresh, the boxes were clean, the arrows pointed in sensible directions. Someone had even colour-coded the domains. The room smelled like optimism and dry-erase fumes. He turned to the group with the kind of grin you only see at the start of a rewrite — the grin of a man who believed, truly believed, that this time would be different.

Six months later, that whiteboard was covered in sticky notes that said “TEMP FIX” and the architecture diagram looked remarkably like the system it was supposed to replace. Because it always does.

“Men do not learn very much from the lessons of history,” Aldous Huxley wrote, “and that is the most important of all the lessons of history.”

That observation belongs in every engineering planning room, right next to the fire exit sign. Because the most seductive idea in software engineering isn’t a new framework, a new language, or a new paradigm. It’s the greenfield project. The blank slate. The promise that if we could just start over, without all this accumulated mess, we’d build something clean. Something right.

It’s also, almost without exception, a lie we tell ourselves to avoid confronting the real problem.

The Seduction of the Blank Slate

You know the pitch. You’ve probably given it yourself — I know I have. It goes something like this: “The current system is too far gone. We’ve been patching it for years. The abstractions are wrong, the data model is a mess, the test coverage is a joke. We need to start fresh.”

And it feels true. When you’re staring at a service that’s been through four team reorganisations, two framework migrations, and a pandemic-era rewrite that was itself never finished, “start fresh” sounds like the only rational option. The codebase has become what I described in a previous post as a victim of code entropy — that gradual, inevitable decay of quality through accumulated decisions made under pressure.

But here’s the thing about entropy that most rewrite advocates conveniently forget: entropy isn’t a property of the code. It’s a property of the system that produces the code. And that system — your team structure, your delivery pressure, your organisational incentives — is coming with you to the greenfield whether you like it or not.

The psychologist Carl Rogers put it plainly: “The curious paradox is that when I accept myself just as I am, then I can change.” The same applies to codebases. Until you accept why the current system looks the way it does — really accept it, not just wave your hands at “tech debt” — you’re not ready to build something better. You’re just ready to build the same thing again, faster.

Why the Constraints Follow You

I had a conversation once with Pete, my boss at the time, about a major system we were considering rebuilding. His observation was devastatingly simple: “We never learnt the lessons of why the website ended up the way it did, so rewriting it we are doomed to make the same mistakes again.”

He was right. And it’s worth sitting with that for a moment, because it’s the core of why greenfield projects fail.

Your current system isn’t messy by accident. Every bizarre workaround, every “temporary” hack, every inexplicable coupling — they’re load-bearing. They exist because someone, at some point, discovered an edge case, a business requirement, a downstream dependency, or a race condition that the clean architecture didn’t account for. The mess isn’t the failure of the original design. It’s the accumulated evidence of reality colliding with intention.

When you start a greenfield project, you’re not escaping those realities. You’re just choosing to rediscover them. The new service still talks to the same downstream systems. It still serves the same business rules. It still handles the same edge cases that made the old system ugly. You’ll encounter every single one of those surprises again — just more painfully, because this time you also have to maintain the old system while building the new one.

Joel Spolsky wrote about this years ago, calling the decision to rewrite from scratch “the single worst strategic mistake that any software company can make.” Netscape did it and nearly destroyed themselves. The original code, ugly as it was, contained years of accumulated knowledge about how the real world actually works.

It’s Not the Code. It Was Never the Code.

I was doing an informal survey a while back, walking around and asking engineers a single question: what do you think is the single biggest issue with our codebase? Just trying to get a feel for how people were thinking. I walked up to Maciej, one of our engineers, and when I asked him, he thought for a moment, then answered: “The engineers.”

We laughed. But he was partly right, and not in the way you might think. It wasn’t an indictment of talent or effort. It was an acknowledgment that people make the decisions about trade-offs. It’s the organisational structure and culture that we build as leaders that guides them to those decisions. And it’s those decisions — thousands of them, made under real constraints, with real deadlines — that lead to the mess.

This is Conway’s Law in its most uncomfortable form: your system will reflect the communication structures of your organisation. Rewriting the code doesn’t change the org chart. It doesn’t change the sprint pressure. It doesn’t change the fact that your product team needs three features shipped by end of quarter and nobody’s going to wait for you to “do it right this time.”

The management thinker W. Edwards Deming was relentless on this point: “A bad system will beat a good person every time.” You can put your best engineers on a greenfield project, give them the latest tools, the cleanest architecture patterns, the most thoughtful design documents. But if they’re operating under the same delivery pressure, the same incentive structures, the same organisational dynamics that produced the legacy system — they will produce the same outcomes. The shortcuts will start small. “Just for now.” “We’ll refactor this next sprint.” “It works, let’s ship it.” And six months later, you’ve got legacy code with a newer timestamp.

The Rewrite Is an Emotional Response

Here’s the part nobody wants to hear: the urge to rewrite is usually not an engineering judgment. It’s an emotional response to complexity.

Complexity is exhausting. Working in a system you don’t fully understand, where changes have unpredictable consequences, where every feature requires archaeology before implementation — it wears you down. And when you’re worn down, the fantasy of a clean start is incredibly appealing. It’s the engineering equivalent of wanting to move to a new city because you’re unhappy. Sometimes the move helps. More often, you discover that the thing making you unhappy came with you in the suitcase.

There’s also a subtler dynamic at play. Greenfield projects are career-enhancing in a way that maintenance work isn’t. “Led the rewrite of the payment service” looks better on a CV than “Incrementally improved the payment service over eighteen months until it was actually reliable.” We’ve created an industry where building new things is glamorous and maintaining existing things is invisible. That incentive structure doesn’t just influence individual behaviour — it corrupts organisational decision-making.

What Actually Works Instead

If rewrites are a trap, what’s the alternative? Do we just accept the mess and live with it forever?

No. But the answer is less dramatic and more disciplined than “burn it down and start over.”

The Strangler Fig Pattern. Instead of replacing a system wholesale, you build new functionality alongside the old system and gradually route traffic to the new implementation. Martin Fowler named this after the strangler fig tree, which grows around an existing tree until it can support itself. The old system doesn’t need to be understood completely, just the interfaces. You migrate piece by piece, proving each piece works before moving to the next. It’s slower. It’s less exciting. It works.

Invest in Understanding Before Deciding. Before you conclude that a system needs replacing, invest serious time in understanding why it looks the way it does. Talk to the people who built it. Read the commit history. Understand the business rules embedded in those ugly workarounds. You might discover that the system is actually doing something remarkably clever in a remarkably ugly way — and that understanding is what you need to improve it.

Fix the System, Not the Symptoms. If your teams keep producing legacy code regardless of the starting point, the problem is upstream of the code. Look at your team structure, your delivery incentives, your definition of “done.” Are you measuring only feature output, or are you also measuring code quality, deployment frequency, and developer experience? What gets measured gets managed — and if you only measure velocity, you’ll get fast code, not good code.

Building the Muscle Before You Need It

This is something I’ve been investing in with my teams, and it comes back to the idea that the problem was never the code — it’s how we think about trade-offs.

We’ve started running what I call “Tethics” moments — like ethics moments, but focused on the technical scenarios engineers face every day. We read a scenario, then talk as a group about what we would do.

Here’s a real one we discussed: A pull request comes in from an external contributor. The code is fast and dirty — technically it works, it has tests, but it doesn’t follow your patterns and would need easily a week of refactoring to clean up. The team is desperate to get it into production to meet their KPI for the quarter, and they argue that since it works, can we please just merge and deploy?

What do you do?

There’s no single right answer. That’s the point. It raises a real tension between delivery pressure and systems ownership, between short-term metrics and long-term health. We talk about it. We listen to each other’s concerns. We align on how we should act so that when this scenario does arise — and it always does — we’re mentally prepared.

We have product people in these conversations too. It helps enormously. When a product manager hears engineers discuss the downstream cost of merging fast-but-dirty code, they start to understand why “it works” isn’t the same as “it’s ready.” And when engineers hear product people explain why that KPI matters, they start to understand why “but it needs refactoring” isn’t always a satisfying answer.

This is how you escape the greenfield trap. Not by writing better code, but by building better judgment. By developing the kind of shared taste and collective decision-making that means your team produces better outcomes regardless of whether the codebase is six days old or six years old.

The Uncomfortable Truth

Every greenfield project becomes a legacy system. That’s not a prediction — it’s a mathematical certainty. The only variable is how quickly it happens.

If you start a greenfield project with the same team dynamics, the same delivery pressure, the same organisational incentives, and the same absence of reflection about why the last system decayed, you will arrive at the same destination. You’ll just have wasted six to eighteen months getting there, while also maintaining the old system and telling everyone that the new one is “almost ready.”

The novelist William Faulkner wrote, “The past is never dead. It’s not even past.” He was writing about the American South, but he could have been describing your microservices architecture. The decisions that shaped your current system — the team structures, the deadline pressures, the trade-off calculus — they’re not relics of some previous era. They’re happening right now, in the new project, to the same people, under the same constraints.

The Bottom Line

The greenfield myth persists because it offers us something irresistible: hope without accountability. The promise that the problem is “out there” in the old code, not “in here” in how we work.

But legacy isn’t about age. A six-month-old codebase can be legacy if the team that built it has already lost the context for why certain decisions were made. And a ten-year-old codebase can be vibrant and maintainable if the team has invested continuously in understanding, refactoring, and improving it.

The most dangerous moment in any engineering organisation isn’t when the old system starts to creak. It’s when someone stands up in a meeting and says, “What if we just started over?” — because that’s the moment you find out whether your leadership has the discipline to ask the harder question: “What would we need to change about how we work to make sure the next system doesn’t end up the same way?”

If you can’t answer that question honestly, the rewrite won’t save you. Nothing will — except doing the slow, unglamorous, deeply important work of understanding why things are the way they are and changing the conditions that made them that way.

Now, if you’ll excuse me, I need to go review a proposal for a greenfield service that will “finally fix” our notification system. The proposal is twelve pages long. The section on what went wrong with the current system is half a page. I’m sure this time will be different.