Ask a payments team which of their applications causes the most trouble and you will sometimes get an odd answer. Not the one that breaks. The one that never breaks.
There is usually a system somewhere in the estate that has run without incident for years. It processes exactly what it is supposed to process. It has never caused an outage. And when a product manager asks for a modest change to it, the estimate comes back in months.
That gap between “it works” and “we can change it” is where a lot of engineering budget quietly disappears.
Reliability and changeability are different properties
Software can be extremely dependable and extremely rigid at the same time. It usually gets that way honestly. Every urgent fix, every regulator-driven patch, every acquisition whose data had to be mapped in over a weekend, all of it left a layer behind. None of those decisions were wrong at the time. The accumulation is the problem.
The symptoms are recognisable. A change to one module triggers regression testing across six others because nobody is confident about the coupling. Business logic lives in three places and the team disagrees about which one is authoritative. The test suite covers the paths that were easy to test rather than the ones that carry money.
None of this appears in an uptime report. It appears in the roadmap, as items that keep getting moved to next quarter.
The knowledge problem underneath
Then there is the human side. The people who built the system have moved on. What remains is documentation written for a version that no longer exists and two or three engineers who understand the thing by memory rather than by reading it.
This creates a bottleneck that compounds. Every change routes through the same small group. Onboarding a new engineer takes months because the knowledge is not written anywhere useful. And those engineers know they are indispensable, which is not a comfortable position for them either.
Teams often treat this as a staffing issue. It is an architecture issue wearing a staffing costume. Systems that are hard to reason about require specialists. Systems with clear boundaries and honest tests can be worked on by anyone competent.
So what’s the solution?
The instinct is to rewrite. Occasionally that is the right call. More often it becomes a two-year program that runs out of political capital in month fourteen, leaving you maintaining two systems instead of one.
The less satisfying alternative works more reliably. Find the parts of the codebase that change most frequently and improve those first. Wrap the stable parts in interfaces so callers stop depending on internals. Write tests around behaviour you are about to change rather than around everything. Extract one capability at a time and prove the pattern before scaling it across the estate.
That is the working logic behind most application engineering services engagements: concentrate effort on the code paths that carry delivery risk, and leave the rest alone until there is a reason to disturb it.
One more thing, frequently skipped: make deployment cheap. Teams instinctively avoid changing systems that are painful to release. Fix the release pipeline and some of the appetite for change comes back on its own, without anyone being told to be braver.
The metric that matters
Uptime tells you the system is running. It tells you nothing about whether the business can get what it needs out of it.
A better question for a quarterly review: how long does it take to get a small, well-understood change into production? If the answer is weeks, that number is your actual constraint, no matter how green the dashboards look.
Stable software that resists change is not an asset holding steady. It is an asset turning into a liability on a timeline nobody is tracking.
About Author
Derek Francis
Derek manages content marketing at Opus Technologies, a domain-native engineering partner for banks, payment providers, and fintechs, and writes on the various aspects of financial institutions navigating change in a real-time, digital-first world.
Top comments (0)