Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase.
No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time.
If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later.
When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems or requirements and you become focused on them.
This sort of deferred work is known as technical debt and it is not your friend, it is a monster that will -on most of the cases- win!
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 re-factoring 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.
Steve McConnell has a lengthy blog entry examining technical debt. The perils of not ackowledging your debt are clear:
The tricky thing about technical debt that is unlike money is that it's impossible to measure it effectively. The interest payments hurt a team's productivity, but since we cannot measure productivity, we can't really see the true effect of our technical debt.
References:
- http://en.wikipedia.org/wiki/Technical_debt
- http://www.javacodegeeks.com/2010/12/things-every-programmer-should-know.html
- http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
- http://martinfowler.com/bliki/TechnicalDebt.html
- http://faheemsohail.com/2011/03/scrum-and-xp-go-hand-in-hand/
No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time.
If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later.
When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems or requirements and you become focused on them.
This sort of deferred work is known as technical debt and it is not your friend, it is a monster that will -on most of the cases- win!
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 re-factoring 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.
Steve McConnell has a lengthy blog entry examining technical debt. The perils of not ackowledging your debt are clear:
One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges. If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.
The tricky thing about technical debt that is unlike money is that it's impossible to measure it effectively. The interest payments hurt a team's productivity, but since we cannot measure productivity, we can't really see the true effect of our technical debt.
References:
- http://en.wikipedia.org/wiki/Technical_debt
- http://www.javacodegeeks.com/2010/12/things-every-programmer-should-know.html
- http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html
- http://martinfowler.com/bliki/TechnicalDebt.html
- http://faheemsohail.com/2011/03/scrum-and-xp-go-hand-in-hand/
No comments:
Post a Comment