"The concept of technical debt is central to understanding the forces that weigh upon systems, for it often explains where, how, and why a system is stressed.
In cities, repairs on infrastructure are often delayed and incremental changes are made rather than bold ones.
So it is again in software-intensive systems.
Users suffer the consequences of capricious complexity, delayed improvements, and insufficient incremental change; the developers who evolve such systems suffer the slings and arrows of never being able to write quality code because they are always trying to catch up."
"Well-written software enables growth in the same way that technical debt obstructs it.
The paradox facing those who manage software development is that continuous delivery of 'quick wins' all too often leads to a seemingly irreversible build up of reckless and inadvertent technical debt, which in turn leads to loss of competitive edge.
Only those organisations which take and retain control of the maintainability of their source code can respond well to consumer demand—they can scale up the size of development teams, and their individual developers are more productive: rather than wasting their time wrestling with mistakes from the past, they deliver that which is needed now, now."
"The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small - such as if it were in a rarely touched part of the code-base.
So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt.
There's another interesting distinction in the example I just outlined. Not just is there a difference between prudent and reckless debt, there's also a difference between deliberate and inadvertent debt. The prudent debt example is deliberate because the team knows they are taking on a debt, and thus puts some thought as to whether the payoff for an earlier release is greater than the costs of paying it off. A team ignorant of design practices is taking on its reckless debt without even realizing how much hock it's getting into."
"I realised today that I need to focus on slowing down, doing things right the first time and making the code elegant, readable, and compartmentalised correctly.
I learnt that the corners you cut one day become the hurdles you have to jump the next…
If we were to extend the complexity of the program without doing some serious work on it, it would quickly become totally unmanageable, and the time it would take to add new features would go through the roof."
"So it is best to introduce a 'debt ceiling'. Just like certain governments…
When debt hits the ceiling, we declare 'debt overflow alert', the doors are closed, all new development stops, and everybody focuses on cleaning up the code until they're all the way back down to the baseline.
The debt ceiling should be set high enough that we don't hit it all the time, and low enough that we aren't irrecoverably screwed by the time we hit it."
"Buying (stocks) on margin is broadly recognized as a risky investment strategy. Funding long-term investments with short-term debt exposes the investor to margin calls as he/she might not be able to secure more financing when needed.
The resultant margin call is never pleasant.
The accrual of technical debt in the course of aggressively developing functions and features is quite a similar phenomenon. The CTO is betting the functionality he/she is developing will pay off before the need to "pay back" the technical debt becomes imperative. The temptation to do so is particularly strong due to the lack of credit limits on technical debt.
For all practical purposes the CTO is 'developing on margin.'"
"Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.
Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.
The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments."
"As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it."
Meir Manny Lehman, 1996
"Laws of Software Evolution Revisited", EWSPT '96 Proceedings of the 5th European Workshop on Software Process Technology: 108–124, Lehman, MM (October 9-11, 1996).
"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."
