The system is strange for a reason

A new engineer joins a team and encounters an unfamiliar system. The architecture looks dated, and several decisions do not match how they would build it today.

It rarely takes long before someone proposes a cleaner replacement. The system is too complicated, its boundaries are wrong, and its technology is old. A modern architecture would be easier to understand and better prepared for the future.

The proposal is usually presented as a technical improvement. Sometimes it is. But sometimes the strongest motivation is much simpler: rebuilding the system is more attractive than taking the time to understand it.

The new design always looks clean because it has not encountered reality yet.

The plumber who wants to rebuild your apartment

Imagine that a faucet in your apartment starts dripping. You call a plumber and expect them to inspect the tap, replace a worn part, and leave you with a working faucet.

Instead, the plumber explains that the entire plumbing system is outdated. They propose replacing every pipe, moving the bathroom, opening several walls, and installing modern devices they have recently been learning about. While they are there, they could divide the plumbing into independently maintainable sections.

Most of us would see red flags. We would ask how a dripping faucet became an apartment reconstruction, question the cost and disruption, and probably call another plumber.

In software engineering, proposals of similar proportions receive serious consideration. A local problem becomes evidence that an application should be rewritten. A difficult deployment becomes a platform initiative. An inconvenient boundary becomes a reason to split a system into services. The proposed solution grows far beyond the original problem, yet organizations still create working groups to explore it.

Software makes reconstruction look cheap

Physical reconstruction has visible costs: materials, permits, opened walls, and immediate disruption. Software creates a dangerous illusion because code has no visible material cost. Replacement can look like a matter of assigning enough engineers and waiting several months.

But a software rewrite does not begin from nothing. It begins with years of behavior that must be rediscovered and reproduced.

The real cost includes undocumented rules, data migration, parallel operation, integrations, operational procedures, and behaviors customers quietly depend on. These costs emerge when the replacement meets the same reality that made the old system complicated.

The existing system looks messy because its compromises are visible. The proposed system looks elegant because its compromises have not been discovered yet.

Working software deserves respect

Software engineers have repeated two phrases for years:

“If it works, don’t touch it.”

“Working software is good software.”

Neither statement is universally correct. Software can work while being insecure, prohibitively expensive, or unable to support what the business needs next. Refusing every change is not engineering discipline; sometimes it is simply fear.

Still, both phrases contain an important warning. Working software has encountered real customers, data, failures, integrations, and organizational constraints that no architecture proposal can fully reproduce.

That does not make it untouchable. It makes it evidence.

Before discarding a working system, we should be able to explain what we are gaining and what we are risking. “The new design is cleaner” is not enough. Cleanliness without context is often just unfamiliarity with the problem.

Strange code may contain forgotten knowledge

Systems that have operated for many years accumulate more than technical debt. They accumulate decisions.

A validation rule may exist because an external system once sent malformed data. A duplicated workflow may reflect contractual differences. An awkward field may preserve compatibility, while a misplaced boundary may reflect operational ownership.

Some of those decisions may no longer be relevant. Others may never have been good decisions. But we cannot tell the difference simply by reading the code and noticing that we would have designed it differently.

Too many improvement proposals treat every existing constraint as a mistake. The team removes the awkward parts before investigating them, then discovers that the awkwardness was carrying information.

Mature systems do not store their knowledge in one document. It is distributed across code, tests, data, support procedures, customer expectations, and the memories of maintainers.

When we rewrite such a system, we are not only replacing technology. We are attempting to transfer institutional memory from a form we do not fully understand into a design that has not yet been tested.

The attraction of starting again

Maintenance requires humility. It asks an engineer to enter a system built by other people, accept that many decisions lack obvious explanations, and spend time learning before suggesting large changes.

A rewrite offers a more flattering position. Instead of studying the existing system, the engineer becomes the architect of the new one. Their preferred patterns become the standard, and their name becomes associated with the transformation.

This does not mean every rewrite is a conscious search for recognition. The incentive is subtler: organizations celebrate launches and new platforms more visibly than another year of stable operation.

A maintenance change may prevent a problem nobody will notice. A rewrite produces diagrams, roadmaps, and new repositories. One looks like a minor task. The other looks like progress.

That difference affects our judgment. Personal preference becomes an architectural principle. Discomfort with unfamiliar code becomes evidence that the code is unmaintainable. The desire to work with newer technology becomes a business case about future scalability.

Eventually, “I would not build it this way” quietly turns into “this system should not exist.”

Sometimes rebuilding is the correct decision

Some systems should be replaced. A rewrite can be justified when the current system cannot meet important requirements, its technology is no longer supportable, security risks cannot be addressed safely, or meaningful changes have become unreasonably expensive.

The difference is that a justified rewrite begins with a demonstrated problem, not aesthetic disappointment. It explains why incremental improvement is insufficient and compares the full cost of replacement with continued evolution.

A responsible proposal treats migration as part of the architecture. It considers how data and integrations will move, how behavior will be compared, and how both systems will operate during the change. It does not preserve every historical decision, but it understands important behavior before removing it.

A rewrite should not be an escape from complexity. It should be a deliberate response to complexity that we understand well enough to change.

Before approving the reconstruction

Large refactorings and rewrites need more than promises of cleaner code and faster development. Before opening the walls, the team should answer:

• What measurable problem are we solving?
• Can we improve it incrementally?
• Which existing constraints have we verified rather than assumed?
• What behavior must the replacement preserve?
• Does the estimate include migration, parallel operation, operational learning, and decommissioning?
• Would we still support the proposal if someone else received credit for building it?

The last question may be uncomfortable. If the proposal becomes less exciting when recognition is removed, the problem may not be entirely technical.

Software should change when the problem requires it, and be replaced when evidence shows that replacement is better than continued evolution.

But unfamiliarity is not evidence, modernity is not a business outcome, and ambition is not an architecture strategy.

Before rebuilding the apartment, fix the faucet—or at least understand why the pipes were placed there in the first place.