Unthought.

The case for doing nothing

Urgency is a property of risk, not of annoyance, and the recommendation to leave a system alone is the one most often left unmade.

The recommendation that goes unmade most often is to leave a system alone. It goes unmade because nobody commissions a review hoping to hear that no action is required, and because an advisor who recommends nothing can feel as though they have delivered nothing — which is a feeling about the advisor, not a fact about the system.

Urgency is a property of risk rather than of irritation, and the two correlate poorly. The system everyone complains about weekly is frequently stable, well understood, and cheap to run. The one nobody mentions is the one with a single maintainer, no backup, and a credential that exists in one place.

A system that works badly but predictably has a known cost. Replacing it trades that known cost for an unknown one, and the unknown one includes the migration, the period during which both systems run and disagree, and the fresh defects that arrive with anything newly written. That trade is sometimes correct and it is never free.

The strongest argument for replacement is rarely that the current system is bad. It is that it is about to become unsupportable: the person who understands it is leaving, the platform is losing support on a published date, the vendor is sunsetting it, or a requirement changed in a way the design cannot accommodate. Those arguments have dates attached, which is what makes them different from dissatisfaction.

Rewrites carry a specific and repeated failure. The replacement gets scoped against what the old system was designed to do, instead of against what it actually does after years of accumulated special cases — and those cases surface one at a time, in production, each individually small and collectively the reason the project runs long.

Where the recommendation is to do nothing, it is stated together with the condition that should trigger revisiting it. That converts inaction from a shrug into a decision with a defined expiry, and it gives whoever raised the concern something concrete to watch, not the sense of having been dismissed.

The useful answer is frequently neither replacement nor inaction but a small intervention: an automated backup, a second person with access, a documented deployment path, a monitor on the thing nobody is watching. These are cheap, they remove most of the risk that prompted the conversation, and they leave the replacement decision available later on better information.

Doing nothing is not the same as ignoring. A system left deliberately alone is still inventoried, still monitored, and still carries a named owner — the decision was to not rebuild it, not to stop looking at it.

Reaching this recommendation is easier for someone with no stake in the alternative, which is a large part of what an outside read is for. A firm that would be paid to do the replacement has to work against its own interest to recommend against it, and the honest response to that is to make the interest visible instead of to claim it does not exist.

Exclusions

What this does not cover.

  • Replacement recommended on the strength of dissatisfaction rather than risk.
  • Do-nothing recommendations with no stated condition for revisiting them.
  • Treating a deliberately unchanged system as one that no longer needs monitoring.