Poor productivity is often a function of legacy

Many organisations believe they have a software productivity problem.

Delivery takes too long. Changes cost too much. Release cycles are slow. Skilled engineers appear to spend weeks making changes that, from the outside, look as though they should take days.

The usual response is to focus on the people doing the work. Introduce better tools. Add automation. Change the delivery process. Ask teams to produce more in less time.

Sometimes that helps. But in a legacy estate, it can also be a response to the wrong diagnosis.

What appears to be poor engineering productivity is often the cost of working inside a system that the organisation no longer understands well enough.

An engineer working on an established application is rarely given a clear problem, a complete specification and a reliable account of how the system behaves. Before changing anything, they must work out which code is actually used, where the relevant business rule lives, what depends on it and whether the documented behaviour still reflects production.

They may need to compare several versions of the same rule, trace an integration that has changed ownership multiple times, read database procedures and deployment scripts, or find someone who remembers why an exception was introduced years ago.

Very little of that work appears in the final change.

A small amendment may produce only a few lines of code while requiring days of investigation. The visible output looks minor because most of the effort was spent establishing whether the change was safe to make.

That is not necessarily poor productivity. It may be rational care applied to an uncertain system.

We tend to discuss software productivity as though it is mainly a property of the engineer or the delivery team. In practice, it is also shaped by the condition of the system around them.

A well-understood application allows decisions to be made with reasonable confidence. Its boundaries are clear enough. Its behaviour can be tested. Its dependencies are visible. Important decisions have been retained somewhere. When something is uncertain, the team has a way of isolating and investigating it.

A poorly understood application creates a very different working environment. Every change becomes partly an exercise in software archaeology. Knowledge is spread across code, documentation, infrastructure, service history and people. Confidence often depends on a small number of experienced individuals who have gradually become part of the operating model.

Those people are then described as bottlenecks.

Often, they are compensating for knowledge the organisation has failed to preserve. Removing them from the process does not remove the dependency. It removes access to the context on which safe decisions still rely.

The difficulty goes beyond technical knowledge because the code is not the whole system.

A working system also includes its data, configuration, integrations, operational procedures and the decisions people make around it. Some of its most important behaviour may never have been encoded.

An underwriter may take a view when a case falls outside the expected pattern. An operations team may know when a failed process can be restarted safely and when it needs investigation. A finance team may perform a manual reconciliation because two systems have never agreed completely.

These are not minor activities surrounding the real system. They are part of how the system produces an acceptable outcome.

They are also hard to discover from source code.

An engineer can therefore implement the apparent rule correctly while changing the real business behaviour. The new code may be technically valid and still be wrong for the organisation using it.

This also creates a problem for human approval.

Putting a person into an approval process does not automatically create understanding. The approver may have formal authority but limited knowledge of the application, the business process or the history behind the decision. They may be accountable for the outcome without having enough evidence to judge it properly.

They may also be asked to review more changes than any person can realistically examine.

There are two pressures here. One is the volume of decisions. The other is the quality of the context available to the person making them. Solving the first does not solve the second.

This becomes more important as AI reduces the cost of producing software. AI can explain unfamiliar code, generate tests, propose implementations and complete many mechanical tasks quickly. Those are real improvements.

But an AI system working with partial context can still produce a convincing answer that misses a dependency elsewhere in the estate. It can generate a technically correct implementation of an incomplete business rule. It can increase the number of proposed changes without increasing the organisation’s ability to determine which changes are safe.

The amount of output grows, but the uncertainty around the system remains.

Engineers may spend less time writing code and more time checking assumptions, resolving contradictions and reviewing machine-generated changes. Domain experts may face a growing queue of questions. Approvers may be presented with evidence they do not have the background to challenge.

AI has not created these problems, but it can expose them more quickly.

Human authority should remain where decisions carry meaningful consequences. That does not mean a person should be expected to reconstruct the entire system before every approval. The surrounding process needs to do more of the exhaustive work: assembling the available evidence, exposing disagreement, identifying what remains uncertain and showing where the consequences may extend beyond the visible change.

The human should be making a bounded decision with useful context, not accepting responsibility for uncertainty that the organisation has left unresolved.

This is why discovery should not be treated as a short preliminary phase before the real modernisation work begins.

Understanding a complex system is productive work. It reduces repeated investigation. It makes dependencies visible. It gives engineers, operators and business owners a shared basis for planning and review.

For that understanding to remain useful, it cannot live only in a document that becomes stale or in the memory of someone who must attend every meeting. It has to become something the organisation can retain, challenge and update as the system changes.

Modernisation should improve this condition.

Moving an application to a newer platform may reduce infrastructure risk. Rewriting components may improve maintainability. Neither necessarily removes the underlying cost of understanding the system.

If the modernised application still depends on undocumented rules, fragmented knowledge and repeated human reconstruction, the technology has changed while much of the productivity constraint remains.

A better productivity conversation would start by asking where the time is really going. Which uncertainties repeatedly delay decisions? What knowledge exists only in people? Why does each delivery team have to reconstruct the same parts of the system before it can act?

Better tools still matter. So do capable teams and disciplined engineering practices. But they cannot compensate indefinitely for an estate that does not provide a reliable account of itself.

Poor productivity is often a function of legacy because the system keeps asking people to establish what is true before they can safely change anything. Until organisations reduce that cost, faster software production will only address part of the problem.

---

This paper is part of The Modernisation Control Papers. Read the complete series on harten.io.