The Technical Debt (also named "Tech Debt" or "Rot Code") is a concept which reflects a technical solution which doesn't fit anymore the needs.
A Technical Debt can be integrated by multiple causes, deliberate or not:
- Business pressure. The business can consider that a feature is released sooner before the code is completed.
- Code is not maintained (We can name this a code which smells! It is maybe where the "Rot Code" term is coming from).
- Lack of knowledge.
- Specification modified at the last minute.
- Other, other and multiple other cases...
Technical Debt: A parallel with the monetary debt.
Each time a mess enters in code, you integrate in the software a "debt". If you don't re-pay this debt (re-worked), you pay "interest" - it means, development time -.
Here, You can see my (very) simple scheme to illustrate the tech debt matter:
- In green, Project A is a project where the code is regularly maintained. It was designed to be growth.
- In red, Project B is a project elaborate for quick market release.
In result, as you see, After few time (matter of weeks or months), the Project B is paying interest compared to Project A.
This is the debt accumulated.
Advantages and dangers of technical debt.
In order to illustrate advantages and dangers of tech debt, I show to you a simple scenario with Project A and B.
Let's do a parallel with a GPS application:
- The first one, Project A is with a code structure well organized. The project is scalable and the team resolves regularly tech debt issues.
- The second one, Project B is not well organized. The tools are not scalable and the priority is fully dedicated to the feature delivery.
- Project B had been released before Project A. Project B costs certainly less than Project A (15$ vs 20$). During the first year, Project B is a must-have and help many drivers to find their way.
- After 1 years, Project A is released and does exactly the same thing as Project B.
- At last, After 2 years, Project B is forgotten: Project A contains many features compare to the concurency ! It can save the home location, has vocal assistance and can foresee the traffic jam! Meanwhile, Project B is sold at the same price and is unable to overtake Project A.
I think you can make the parallel with multiple projects in the software industry.
Indeed, you got it! Even if Project B was a success story at the beginning, the management didn't dedicate resources to resolve the accumulated debt. In the long term, adding features became painful and the development team was under a permanent pressure. Money is lost, developers and managers was under pressure and the project is disbanded. This is a doomed fate...
Tech debt accumulation
How tech debt can impact a Sofware project
Pros
Cons
Conclusion:
The technical debt accumulation is extremely dangerous in medium and long term.
Unfortunately, even if this concept is well known by developers, managers ignore regularly how many tech debt is accumulated in projects. Indeed, the tech debt is hard to estimate in terms of time and money lost.
Personally, I already joined a new formed team to recover a project with a huge quantity of technical debt. Despite the fact to release quickly, we stayed professional. We proposed for each release a simple refactoring of the code or redesign of messed parts. Some of my previous colleagues are reading my blog, they will recognize! =)
In result, after one year, the project became cleaner and the environment "developer friendly".
The Technical Debt is an extremely large subject and treated in many blog posts and books. Here, I featured to you only a tiny part. I'll certainly review this subject for another blog post (specially to tell you my experience in this project with many tech debt!).
For more information, you can view this presentation from Steve McConnel.
In parallel, tech debt can be caused by design not secured or other messes, don't hesitate to review my blog posts about security or clean code: