When I first worked on modernising a COBOL application, I expected the biggest challenge to be the technology, the same mistake many teams make when they treat modernising runtime without rewriting business logic as mostly a platform exercise.
COBOL had a reputation for being difficult to understand. The application had been evolving for decades, and like many legacy systems, it had accumulated years of enhancements, fixes and business changes.
But the code wasn’t the biggest obstacle.
The knowledge was.
One person understood how critical parts of the system worked. Everyone else relied on that person for answers. There was little cross-training, limited documentation and no effective way of sharing the reasoning behind many of the business rules.
The result wasn’t just slower development.
It was more defects.
At the time, I saw this as an organisational problem. Looking back, I think it was something more fundamental.
It was entropy.
Software Systems Behave Like Physical Systems
One of the central ideas in thermodynamics is the Second Law: left alone, closed systems naturally move towards greater disorder unless energy is continually applied to maintain order. In physical terms, OpenStax describes entropy as the thermodynamic variable used to express the second law, while NASA’s Glenn Research Center explains that irreversible processes increase entropy across the system and environment.
See: OpenStax on entropy and NASA on the second law and entropy.
A tidy desk becomes cluttered.
A maintained garden becomes overgrown.
A house slowly deteriorates without upkeep.
Enterprise software follows the same pattern.
No system starts life as a tangled web of exceptions, duplicate logic and undocumented processes. They become that way over years of responding to changing business requirements, regulatory updates, production incidents and staff turnover.
Disorder isn’t a sign that engineers failed.
It’s the natural state of systems that have been evolving for a long time.
Not All Technical Debt Lives in the Code
Technical debt is usually discussed in terms of poor design, outdated frameworks or code that should have been refactored years ago. Ward Cunningham introduced the debt metaphor in 1992, and later research has broadened it beyond code into architecture, design, documentation, requirements and testing. A 2015 systematic mapping study in the Journal of Systems and Software classifies technical debt into multiple types and notes that code-related debt has received the most attention, even though the metaphor has expanded across the software lifecycle.
See: A systematic mapping study on technical debt and its management.
Those things certainly exist.
But during this project, I found another kind of debt that was far more expensive.
Knowledge debt.
This is close to what recent discussions call cognitive debt: the erosion of shared understanding faster than a team replenishes it. The terminology is newer than the technical-debt metaphor, but the underlying problem is older: maintenance cost rises when the artifacts needed to understand a system become incomplete, stale or inaccessible.
Critical business knowledge had become concentrated in one individual. Over time, understanding of the system stopped being shared across the team. Documentation wasn’t kept current, cross-training became rare and decisions were preserved only in someone’s memory.
The software continued to evolve.
The team’s shared understanding did not.
Knowledge Silos Increase Entropy
Knowledge silos don’t always form because people have bad intentions.
Sometimes teams are simply too busy to document what they’ve learned.
Sometimes experienced developers become the default experts because they’re the only ones trusted to make risky changes. The pattern is familiar in systems that survive longer than their platforms: the runtime persists, but the social system that once understood it decays.
In my experience, there was another factor.
People wanted to retain their edge.
If only one person understands a critical system, that knowledge becomes a form of job security. The intention may not be malicious, but the outcome is the same: knowledge becomes concentrated instead of distributed.
From an organisational perspective, that is entropy.
The information still exists.
It just isn’t available to the people who need it.
Defects Are Often Symptoms of Missing Knowledge
As new developers worked on the application, they encountered gaps in understanding rather than gaps in code.
Business rules weren’t obvious.
Exceptions weren’t documented.
Dependencies weren’t fully understood.
Developers made reasonable assumptions based on the information available to them.
Sometimes those assumptions were wrong.
The result was more defects.
The defects weren’t caused by poor programming.
They were caused by incomplete knowledge.
That distinction matters because fixing the code alone doesn’t address the underlying problem. A similar failure shows up in configuration drift in production systems: the visible defect is local, but the cause is often missing shared state about what the system is supposed to be.
Applying Energy to the System
Thermodynamics tells us that maintaining order requires energy.
Software systems are no different.
The energy isn’t electricity or processing power.
It’s the continuous effort required to preserve shared understanding.
That includes:
- documentation
- code reviews
- cross-training
- mentoring
- architecture discussions
- removing obsolete code
- explaining why decisions were made, not just what changed
These activities are often viewed as overhead because they don’t immediately deliver new features. Research on technical debt management describes the same trade-off in lifecycle terms: short-term development choices can create future maintenance costs that have to be identified, monitored and repaid. A 2017 systematic mapping study found that technical debt decisions are context-dependent and require explicit management rather than occasional cleanup.
See: Identification and analysis of the elements required to manage technical debt.
In reality, they’re the work that prevents entropy from accelerating.
Where AI Helped
As part of the modernisation effort, we introduced Azure OpenAI with Retrieval-Augmented Generation (RAG) to help engineers explore the application. That use case is less about “AI replacing developers” and more about recovering business knowledge from legacy systems.
AI proved remarkably good at explaining COBOL programs, identifying business rules and answering questions about unfamiliar parts of the system.
It reduced the time needed to understand existing functionality and made knowledge easier to discover.
What it didn’t do was eliminate the knowledge silo.
The AI could recover information that already existed across source code and documentation.
It couldn’t create organisational knowledge where none had been captured. That boundary matters for AI adoption generally: legacy systems expect deterministic architecture, while AI introduces probabilistic outputs.
That’s an important distinction.
AI reduced the cost of navigating complexity.
It didn’t remove the complexity itself.
Documentation Changed the Outcome
The real improvement came after recovered knowledge was documented.
As business rules became explicit instead of implicit, more people could understand how the application worked.
The dependency on a single expert began to decrease.
Knowledge became easier to verify, discuss and improve.
Most importantly, defects reduced.
Not because the software had suddenly become simpler.
Because the organisation had become more ordered.
Modernisation Is Really Knowledge Recovery
Many organisations approach legacy modernisation as a technology problem.
Replace COBOL.
Move to the cloud.
Rewrite the application.
Adopt AI.
Those initiatives can all deliver value.
But they’re unlikely to succeed if the underlying knowledge remains trapped inside individuals or scattered across decades of undocumented decisions. Rewrites fail for the same reason when teams ignore the rules of time embedded in legacy systems.
Before software can be modernised, the organisation has to recover its understanding of how that software supports the business.
Technology accelerates that process.
It doesn’t replace it.
Final Thoughts
Working on this project changed how I think about technical debt.
I used to think it accumulated primarily through poor code.
Now I believe the larger problem is accumulated knowledge that becomes progressively harder to access.
As knowledge becomes concentrated in individuals, undocumented decisions become accepted behaviour and shared understanding gradually disappears, defects become almost inevitable.
That’s entropy at work.
AI has an important role to play in modernising legacy systems. It can help engineers recover knowledge that would otherwise take days to uncover, making complex systems more approachable and reducing the effort required to understand decades of accumulated software.
But recovery is only the first step.
If that knowledge isn’t documented, shared and maintained, the system will continue to drift towards disorder.
Technical debt isn’t just the accumulation of bad code.
It’s the accumulation of knowledge that becomes harder to access over time.
The code is simply where that debt becomes visible.
