WritingCost of change
Seven signs your software has become too expensive to change
A system rarely announces that it has become too expensive to change. The evidence arrives as symptoms that each look like something else — a slow estimate, a nervous release, a spreadsheet nobody asked for. Taken together they describe one condition, and each points to a cause that can be measured.
- Written by
- Dorian Ben Haim, Principal
- Published
- Reading time
- 7 minutes
In short
- Old technology is not the thing to look for. The thing to look for is change cost: how long a change takes, how risky it is, and how many specific people it depends on.
- Seven signs point to it: small changes estimated in quarters, releases treated as events, integrations that fail where customers notice first, changes that touch half the system, knowledge held by one person, data moved by hand, and a system that blocks decisions already made.
- Each sign has a likely cause and something measurable behind it — in ticket history, deployment logs, version control and the time operations staff spend.
- The signs establish that change has become expensive. They do not establish why, and the cause decides the remedy.
The condition
Change cost is the number that matters
Every system accumulates age, and most accumulate technical debt. Neither is the problem by itself. A ten-year-old system that absorbs change cheaply is an asset. A two-year-old system where every change is a negotiation is not.
The number that matters is the cost of change: how long a change takes to get from request to production, how likely it is to break something on the way, and how many specific people it depends on. When that number rises, it surfaces as symptoms — and because each symptom lands in a different part of the business, they are rarely recognized as one condition. Engineering sees estimates. Operations sees workarounds. Leadership sees commitments slipping.
The signs
Seven signs, and what each one tends to mean
Any one of these can have an innocent explanation. Several together, persisting for months, describe a system that has stopped absorbing change cheaply.
- Small changes are estimated in quarters
- A change that sounds local — a new field, a new rule, a new report — comes back estimated as a project, and nobody can quite explain the gap. It tends to mean the system has no boundaries where it needs them: the change cannot be made in one place, so its cost includes understanding, modifying and re-verifying parts of the system that have nothing to do with the request.
- Releases are events
- Releases are scheduled, batched and staffed. People plan their weekends around them, and one person knows how to do them. This tends to mean deployment is manual or partly automated and verification happens by hand. It also feeds itself: risky releases get batched, and bigger batches make each release riskier.
- Integrations break, and customers notice first
- Orders go missing between systems, a partner feed stops updating, a nightly job fails and nobody knows until morning. When operations staff or customers are the detection mechanism, it tends to mean the integrations were built to work rather than to fail visibly — no alerting, no reconciliation, and errors that are logged and forgotten.
- One change touches half the system
- A modification that ought to be local requires edits in five places, by someone who knows where all five are. It tends to mean business rules are duplicated, components share a database without agreed boundaries, or a concept the business treats as one thing is implemented differently in several places.
- Critical knowledge lives in one person’s head
- There is a part of the system that only one person can change safely, and work on it waits for them. It tends to mean the behaviour was never written down or pinned by tests, so that person has become the specification — a risk that stays invisible until they are unavailable.
- People move data between systems by hand
- Someone exports from one system and imports into another, reconciles two reports that should agree, or re-keys orders from email. It tends to mean an integration is missing or unreliable, and the business has quietly built a headcount cost around it.
- The system blocks decisions already made
- The business has committed to a new product, market, partner, pricing model or regulation, and the system cannot absorb it without a project nobody planned. It tends to mean an assumption was built into the architecture — batch rather than real-time, one currency, one tenant, one way to price — and the business has outgrown it.
What to measure
How to measure each sign before deciding anything
Each sign can be turned from frustration into evidence, mostly from data the organization already has. None of it needs new tooling to start.
| Sign | What to measure | Where the data is |
|---|---|---|
| Small changes estimated in quarters | Estimate against actual for recent changes, and where the time went: analysis, coding, testing, release, coordination | Tickets and estimates; the people who did the work |
| Releases are events | How often you deploy, how long a change takes to reach production, how often releases fail, and how long recovery takes | Deployment logs, CI history, incident records |
| Customers notice integration failures first | For each integration: how a failure is detected, and how long it takes between failure and detection | Incident history, support tickets, logs |
| One change touches half the system | Which files and components change together, and how many places a single business rule lives in | Version-control history |
| Knowledge in one person’s head | Which areas only one person changes, and what waits when they are away | Version-control history; the team’s own account |
| Data moved by hand | Hours per week spent moving and reconciling data, and how often it goes wrong | The operations team |
| The system blocks decisions | Commitments delayed or declined because of the system, and what the delay cost | Product and sales leadership |
The second row describes the delivery measures that DORA, the DevOps Research and Assessment programme, uses for software delivery performance: how quickly a team can change a system, and how safely. They are worth tracking continuously, because they show whether later work is actually reducing the cost of change.
Cost, not cause
The signs show the cost, not the cause
Recognizing several of these signs establishes that change has become expensive. It does not establish why, and the cause decides the remedy. Estimates in quarters can come from missing boundaries or from a release process that adds weeks to everything. A knowledge bottleneck can be a documentation problem, or an architecture that only one person can hold in their head.
This is where expensive mistakes are made. The remedies on offer — a rewrite, a cloud migration, a new platform — are large, and each fixes a specific cause. Chosen before the cause is known, they tend to move the problem rather than remove it. Why rewriting a legacy system is often the wrong first move covers the largest version of that mistake.
The question is never how old the system is. It is what a change costs, and why.
The alternative is to diagnose first: measure the signs, trace the causes, and fix the ones that carry the most cost — incrementally, as described in how to modernize a legacy system without rewriting it.
Questions
Questions and answers
How do you know if technical debt is a real problem?
When it creates change cost. Debt matters when changes take longer, fail more often or depend on specific people because of the state of the code. Debt in code that nobody needs to change costs nothing and can wait.
What are DORA metrics?
Measures of software delivery performance from the DevOps Research and Assessment programme. They cover how quickly a team ships changes — how often it deploys, and how long a change takes to reach production — and how safely: how often changes fail, and how long recovery takes.
Is an old technology stack a sign that a system needs replacing?
Not by itself. Age matters when it creates cost or risk: an unsupported runtime, missing security fixes, no engineers available to work on it. A supported stack that is expensive to modify needs more attention than an old one that absorbs change cheaply.
What should we do if we recognize several of these signs?
Measure before choosing a remedy. Trace recent changes, check how integration failures are detected, and find where knowledge is concentrated. The cause decides the fix, and choosing a large remedy — a rewrite, a migration, a new platform — before knowing the cause is an expensive way to move the problem rather than remove it.
How long does it take to find the cause?
For a single system, a focused investigation of a few weeks can establish where change cost accumulates and why — provided it has access to the code, the deployment process, the logs and the people who work on the system every day.
Written by
Dorian Ben Haim leads Antegrate, a principal-led software engineering consultancy for business-critical systems that have become hard to change. About the practice