In a COBOL modernisation project, the largest obstacle was the concentration of business knowledge. One person understood critical parts of the application, while other engineers depended on that person to explain rules accumulated over years of changes.
The code was available. The reasoning was much harder to recover.
This is the useful idea behind the thermodynamics of technical debt: maintaining a comprehensible system requires continuing effort as the software, its environment, and the people responsible for it change.
Thermodynamic entropy is a physical concept, not a measurable law of software deterioration. Source code does not become disordered merely because time passes. The metaphor becomes useful only when it directs attention to specific mechanisms, such as undocumented exceptions, diverging configurations, duplicated rules, and lost knowledge.
Technical Debt Appears as Additional Work
Technical debt describes internal weaknesses that make later development harder than it needs to be. Martin Fowler’s explanation develops the financial analogy: extra effort caused by those weaknesses resembles interest, while improving the structure resembles repayment.
In the COBOL system, changing a calculation could require finding the only person who understood its exceptions, reconstructing why they existed, and identifying which downstream jobs depended on them. The visible code edit might take little time compared with that investigation.
Some of this effort is unavoidable domain complexity. A business with several generations of customer agreements may genuinely require several calculation paths. Debt lies in avoidable difficulty understanding and changing those paths, not simply in their number.
That distinction prevents an attractive cleanup from deleting meaningful behaviour.
Disorder Accumulates Through Local Decisions
A team adds an exception to meet a deadline. Another team copies the rule into a reporting service. Operations changes a setting during an incident, and the reason remains only in a conversation.
Each action can make sense locally. The combined system now contains relationships that are harder to discover and keep consistent.
This is a feedback loop that an organisation can interrupt. It is not inevitable physical decay.
For example, recording the reason for an exception and its affected contracts can make the next change safer. Removing a duplicated calculation can eliminate an entire category of reconciliation work. The intervention should match the mechanism producing the cost.
Knowledge Concentration Makes Change Fragile
An experienced maintainer often becomes the default reviewer because they can identify risks that others miss. Over time, the team may route more work through that person, leaving fewer opportunities for colleagues to learn.
The immediate process can appear efficient: ask the expert and receive an answer. The longer-term effect can be a queue around one person’s availability and a growing gap between what the system does and what the team can explain independently.
Documentation helps when it captures questions people actually need to answer. For a calculation, that might include the business purpose, effective dates, examples, exceptions, dependencies, and the source of the rule.
Pairing on real changes gives another engineer an opportunity to use that information. The practical test is whether someone else can investigate and modify the area with appropriate review, rather than whether a document exists.
Age and Technical Debt Are Different
An old component can be stable, well understood, and inexpensive to operate. A recently built service can contain unclear responsibilities and tightly coupled dependencies.
Similarly, new requirements do not automatically indicate debt. Evolutive maintenance is necessary because useful software must respond to changing needs. Good design reduces avoidable effort; it does not eliminate change.
Fowler’s technical debt quadrant also distinguishes deliberate decisions from weaknesses discovered through learning. Teams can reasonably learn that an earlier design no longer fits without having acted negligently.
The useful response is to identify the current constraint and its consequences. Blaming the age or language of the application provides less guidance than showing which changes repeatedly require expensive coordination.
AI Can Help Retrieve Knowledge That Has Been Captured
The COBOL modernisation work also used retrieval-augmented generation to help engineers explore the application. That approach can make relevant code and documentation easier to locate and compare.
Its value depends on the material available. An assistant can retrieve a calculation path without knowing whether an undocumented exception still serves an active agreement. A plausible explanation is a starting point for investigation, not evidence of business intent.
Keep answers connected to source material and verify important claims against code, examples, records, and knowledgeable reviewers. When an investigation resolves an uncertainty, record the finding somewhere maintained by the team.
That process turns a one-off answer into shared knowledge. Simply adding an AI interface over incomplete records can make information easier to search while leaving the underlying ambiguity intact.
Prioritise Debt Through Recurring Consequences
A long inventory of undesirable code does not establish what should be fixed first. Look for repeated costs or risks in areas the organisation expects to change.
| Observation | Possible intervention | Evidence of improvement |
|---|---|---|
| Changes wait for one expert | Pairing and maintained rule examples | More people complete investigations safely |
| One rule differs across services | Establish an authoritative implementation or contract | Fewer inconsistent outcomes |
| Releases need repeated manual repair | Improve deployment and configuration control | Fewer recovery steps and failed releases |
| Historical cases break after changes | Preserve effective rules and regression examples | Fewer unexplained behavioural differences |
These are hypotheses to investigate, not automatic prescriptions. Centralising a rule may introduce an unacceptable runtime dependency; the design needs to consider that trade-off.
Use bounded improvements where possible. Simplifying one frequently changed area can provide evidence before committing to a broad restructuring programme.
Modernisation Should Preserve Understanding
Changing the platform can remove unsupported dependencies or improve operation. It does not automatically explain the business rules that were poorly understood before the move.
Modernising the runtime without rewriting business logic can be valuable when it separates platform risk from behavioural change. That separation still requires evidence about the behaviour being retained.
The lasting benefit comes from improving the team’s ability to operate and change the system. Tests, decision records, clear ownership, and shared knowledge contribute when they reduce actual uncertainty.
The entropy metaphor is useful at that level: it reminds us that coherence needs maintenance. Engineering decisions become stronger when the metaphor gives way to a specific dependency, cost, or knowledge gap that the organisation can address.
Key Takeaways
- Software entropy is a metaphor; identify concrete causes of growing change costs.
- Technical debt includes avoidable difficulty, not every form of business complexity.
- Knowledge sharing must make independent investigation possible.
- Prioritise improvements using recurring consequences and evidence of reduced effort or risk.
