In Praise of the Caretakers: The Case for Engineers Who Fix Rather Than Replace

There is a hierarchy of prestige in software engineering, and it is not subtle. The architect who designs a greenfield system from a blank page sits near the top. The engineer who ships a new product in time for a launch event gets the press release. The person who spends eleven months quietly untangling a billing system written in 2009 by a team that has long since dispersed? That engineer rarely makes the conference talk circuit.

I have spent the better part of two decades on both sides of this divide, and I want to make an unfashionable argument: the most valuable engineers I have ever worked with — the ones clients should seek out and companies should promote — are the ones who treat existing software as something worth caring for. The industry calls this maintenance, a word that sounds like plumbing. I have come to think of it as stewardship, and it is chronically under-rewarded.

The Rewrite Trap

Consider a pattern I have now watched play out at three different organizations, most recently at a mid-sized logistics firm outside Columbus, Ohio. Their order-tracking system was old, undocumented, and understood by exactly two people, one of whom had announced his retirement. The instinctive response — and the one recommended, at considerable expense, by a well-regarded consultancy — was a full rewrite. Eighteen months and a seven-figure budget, the proposal promised, and the legacy system would be retired.

Twenty-six months later, the rewrite was still in progress. The problem was not incompetence. The problem was that nobody, including the new team, fully understood what the old system did. Every edge case in twenty years of accumulated business logic — the regional fuel surcharge, the customer who negotiated a custom pallet rule in 2014 — had to be reverse-engineered before it could be reimplemented. Meanwhile, the legacy system kept running, accumulating changes, drifting further from the target.

The rescue came from an engineer who did the opposite of what everyone expected. She stopped the rewrite, spent six weeks writing characterization tests against the legacy code, and then began refactoring the existing system module by module. Two years on, the system is modern enough, stable, and — critically — understood by more than two people. Total cost was a fraction of the rewrite estimate.

This is not an argument against ever rebuilding software. Some systems genuinely cannot be saved. But the default industry reflex toward replacement, rather than repair, deserves scrutiny. Rewrites are glamorous and grant-funded. Refactoring is neither, and so it happens less than it should.

Why Stewardship Loses the Incentive Game

The imbalance is structural. A new system produces a launch, a demo, a portfolio entry. Careful maintenance produces the absence of incidents, which is invisible by design. No one throws a party for the outage that did not happen.

Compounding this, the economics of consulting reward novelty. A client engagement structured around building something new has a clean scope and a clear endpoint. An engagement structured around understanding and improving what already exists is harder to sell and harder to price — which means the market quietly selects for builders, and the caretakers drift toward in-house roles where their value accumulates but goes unnamed.

The result, in my observation, is a genuine shortage. Organizations that find an engineer or consultant willing to engage deeply with their existing systems — to read the code, interview the operators, and improve rather than replace — tend to keep those relationships for years. The value of that continuity compounds in a way a one-off build never does.

A Checklist for Hiring a Caretaker

If you are evaluating a developer or consultant and want to know whether they will still be adding value eighteen months after launch, ask questions that reveal their orientation toward existing systems:

• Ask them to describe a system they inherited and improved. A builder will tell you about what they replaced. A steward will tell you what they preserved and why.
• Watch how they talk about the previous team. Caretakers speak about legacy code with curiosity, not contempt. Contempt is a warning sign that they are already planning the rewrite.
• Ask what they will leave behind. A steward answers in terms of documentation, tests, and a team that no longer depends on them. A builder answers in terms of features shipped.
• Probe their exit strategy. Ask directly: how will you make yourself unnecessary? Vague answers suggest an engagement designed to renew itself indefinitely.
• Request a small, unglamorous first project. Give them a bug fix or a monitoring improvement rather than a new feature. How they handle the unglamorous work tells you more than any pitch deck.

None of this is a personality test. It is a test of incentives and habits, both of which are far more predictive than a portfolio of launch screenshots.

Building a Culture That Keeps Its Caretakers

For engineering leaders, the practical question is how to make stewardship visible. A few practices have worked in organizations I have advised: track and celebrate reliability improvements with the same fanfare as feature launches; include maintenance work in promotion criteria explicitly, not as an afterthought; and rotate engineers through the systems nobody wants to touch, so knowledge spreads instead of concentrating in one departing employee.

The alternative — a culture that only rewards the new — produces the Columbus scenario on repeat: brittle systems, rewrite debt, and a quiet exodus of the engineers best equipped to prevent both.

Software, unlike most things we build, does not wear out from use. It wears out from neglect. The engineers who understand this — who approach an inherited codebase the way a good forester approaches an old stand of trees — are not a lesser tier of the profession. Increasingly, I would argue they are the standard by which the rest should be measured.