A Crazy Amount of Money
Let's leave the wonderful world of innovation to dive into the mechanics of computing. The computing that powers banks, governments, the world. We're going to talk, very calmly and very simply, about a poison that paralyzes all programs. A slow, inevitable, and often unknown poison: technical debt.
Technical Debt Paralyzes the Economy
This is important.
You're not a developer?
You're not interested in computing?
Stay with us.
This post was written for you.
Hang on, it's worth your time.
Technical Debt
Writing programs is good.
Evolving them over time is better.
We're going to talk about software engineering.
And more precisely about technical debt.
It's a frankly complex subject.
But you're going to understand everything :-)
I promise.
Programming
All programs evolve.
Needs change, libraries transform, data formats change.
It's necessary to reflect these modifications in the programs.
Either to maintain their operation.
Or to improve it.
It's natural.
Be Quick or Be Dead
"Could you change this for tomorrow?".
Every developer has heard this phrase.
And sighed...
They know that going fast is a bad idea.
It's counterproductive.
Quick modifications often ensure a future headache.
Going fast leads to suboptimal choices.
Complexity
Adding features or making quick corrections means adding code or complexity. Or both. A developer works poorly when under the pressure of a deadline. Poorly written code, introduction of bugs, crashed backups, compromised security, unnecessary dependencies or files, documentation rarely updated... Your code evolves quickly? Maintenance will be difficult.
Maintenance
This new code poses a problem. It doesn't integrate naturally? It breaks certain functionalities? It disturbs the internal logic of processing? There can be numerous reasons. The consequence is clear. Maintenance of the new code will be more difficult. This means that costs will be higher and deadlines longer.
« Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. » Ward Cunningham (1992)
Ward Cunningham is a leading figure in software engineering.
Debt is Inevitable
External dependencies, language evolution, lack of developers competent in this tech (FORTRAN, C, COBOL), changing specifications, etc. Debt is inevitable. It accumulates until its interests paralyze the project. It must therefore be anticipated and managed. It is then necessary to partially rewrite the code. By refactoring, for example. Or by revising the design or data models.
A Delicate Balance
A program is a delicate dynamic balance. The three words are important. Balance: the program correctly meets the needs (=specifications) Dynamic: the program can be satisfactorily modified (time, costs). Delicate: human, material, computing conditions evolve constantly (such is life). The viability zone of a program is therefore very restricted. Even small modifications threaten this balance.
Cherish Your Programs
Taking care of your programs is an economic and operational necessity. ... You don't believe me? Let's take the example of the Y2K bug. A single language is linked to a quarter of the expenses. Dates were noted XX instead of 19XX. This example illustrates the impact of technical debt well. So, we're going to talk about COmmon Business Oriented Language.
COBOL
COBOL is an old language (1959). It dates from the beginnings of computing. Many data processing programs were initially written in COBOL in the 60s and 70s. They have never been translated into more recent languages, for various reasons too long to develop here. These software are still massively used in large organizations, especially in the banking system or government institutions.
800,000,000,000
t's estimated that more than 800 billion lines of COBOL are still in production on mainframe computers. Maintaining these types of old systems is difficult. The people who wrote these programs have retired or passed away. Therefore, the technical debt is phenomenal. These software systems are used in production, and their maintenance must be assured, which is no small feat. Worse still, these ancient programs sometimes need to be updated, requiring modifications to software that may be 60 years old.
A Nightmare
The maintenance costs are astronomical!
The costs of rewriting are prohibitive.
The interest on the debt continues to accumulate.
Consequently, companies find themselves trapped, forced to maintain systems they know are dysfunctional at any cost.
It's absurd.
Does This Scare You?
Me too.
And for good reason.
Technical debt is a scourge, a necessary evil that can and must be managed.
Do not build your new tools without taking technical debt into account.
Did You Know?
AI systems are particularly susceptible to technical debt.