When teams say they want a rewrite, what they are usually reaching for is not a cleaner codebase but a reset of boundaries. What belongs where, who owns what, and how the system is divided up no longer feels workable.
In that sense, rewrites are rarely just internal technical improvements. They are attempts to redraw the system as a whole.
Unlike a refactor that seeks to improve structure within existing boundaries, a rewrite implicitly questions the boundaries themselves.
The problem is that these two things often get conflated.
Teams assume they are only changing implementation details, when in fact they are trying to change how the system is partitioned.
That is why rewrites feel so disruptive and so uncertain. They are not just technical exercises, they are structural reorganisations.
And importantly, boundary problems cannot be solved inside the code alone. They are shaped by how the system is understood and operated.
Complexity emerges when code stops matching the system it lives in
Code becomes complex not because it is inherently messy, but because it no longer maps cleanly to how the business actually works, how teams are structured, or how work flows through the system.
When that mapping is reasonably aligned, changes are predictable. You can trace a feature from concept to implementation without too much cognitive load.
But when the mapping drifts, every change becomes a translation problem. Product requests don’t cleanly map to domain concepts. Domain concepts don’t map cleanly to the code. And ownership boundaries in the team do not align with either.
This is where friction accumulates.
Yet even when the code itself is well-written, complexity will still emerge if the underlying domain is unclear or inconsistently represented. Any ambiguity in the domain model will be reflected downstream in the architecture.
The code does not just implement the domain — it inherits its structure, including its confusion.
This is why complexity is not purely a technical property. It is a property of how well the system’s structure mirrors the reality it is trying to represent.
Rewrites are boundary changes, not just code changes
Rewrites usually focus on improving the fidelity between code and the domain model. The understanding of the problem deepens and engineers see new solutions to old problems.
Yet even if they do succeed at realignment temporarily, if the organisational structure and domain understanding remain unchanged, the same pressure points reappear.
The underlying boundaries won’t actually have been resolved. They will have just been re-expressed.
This is why systems often end up in a familiar place after a rewrite: cleaner code, similar coordination costs, and the same kinds of delivery friction re-emerging over time.
Real improvements come from tightening alignment across multiple layers. Simplifying the domain model and clarifying its boundaries so they can be reflected consistently in code. And ensuring those same boundaries are reflected in how teams, responsibilities, and workflows are structured.
When those align, complexity does not disappear, but it becomes localised and manageable. Changes stop leaking across the system. And the need for a rewrite usually fades — not because the system became simple, but because it became coherent.