Monday, June 27th, 2016
Technical Debt: is the obligation that a software organization incurs when it chooses a design or construction approach that’s expedient in the short term but that increases complexity and is more costly in the long term.
We can incur in tecnical debt unintentionally (writing bad code) or intentionally (making a conscious decision to optimize for the present rather than for the future).
The most important implication of technical debt is that it must be serviced, i.e., once we incur a debt there will be interest charges. If the debt grows large enough, the company could spend more on servicing its debt than it invests in increasing the value of its other assets. So we have to pay down the debt as soon as possible and we can use different ways:
- Slower development due to complexity is like paying interest
- Refactoring is like repaying principal
- Replacing the system is like paying down the debt in one lump sum
In order to avoid incurring technical debt, we have to develop software in maintenance mode, building quality from the start, taking always into account the maintainability of the system.
Get out of Technical Debt Now !
There is never time to do it right, but doing it wrong will lead to failure. We have to find a way to do things right and not accumulate technical debt or we will find ourselves under a mountain of interest that we will not be able to pay off
Summing-up: Don’t let the debt build up. Remove cruft as we go. Build simplicity and clarity in from the beginning, and never relent in keeping them in.
These Notes have been taken from:
- The term “Technical Debt” was coined by Ward Cunningham.
- The post How Managing your Technical Debt will ensure your Software Quality.
- The post Technical Debt.
- The post DevOps and Technical Debt: A Debt Crisis in Your Workplace?.