This post originated from an RSS feed registered with Agile Buzz
by Martin Fowler.
Original Post: TechnicalDebt
Feed Title: Martin Fowler's Bliki
Feed URL: http://martinfowler.com/feed.atom
Feed Description: A cross between a blog and wiki of my partly-formed ideas on software development
Update: Added a link to Ward Cunningham's video opinion
You have a piece of functionality that you need to add to your
system. You see two ways to do it, one is quick to do but is messy -
you are sure that it will make further changes harder in the future.
The other results in a cleaner design, but will take longer to put in
place.
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.
The tricky thing about technical debt, of course, is that unlike
money it's impossible to measure effectively. The interest payments
hurt a team's productivity, but since we
CannotMeasureProductivity, we can't really see the true
effect of our technical debt.
One thing that is easily missed is that you only make money on
your loan by delivering. Following the
DesignStaminaHypothesis, you need to deliver before you
reach the design payoff line to give you any chance of making a gain
on your debt. Even below the line you have to trade-off the value you
get from early delivery against the interest payments and principal
pay-down that you'll incur.
(As far as I can tell, Ward first introduced this concept in an
experience report for OOPSLA
1992. It has also been discussed on the wiki.)
Additional Comments
Ward Cunningham has a video talk where he discusses this
metaphor he created.
A couple of readers sent in some similarly good names. David
Panariti refers to ugly programming as deficit programming.
Apparantly he originally started using a few years ago when it fitted
in with government policy; I suppose it's natural again now.
Scott Wood suggested "Technical Inflation could be
viewed as the ground lost when the current level of technology
surpasses that of the foundation of your product to the extent that it
begins losing compatibility with the industry. Examples of this
would be falling behind in versions of a language to the point where
your code is no longer compatible with main stream compilers."
Steve McConnell brings out several good points in the metaphor,
particularly how keeping your unintended debt down gives you more
room to intentionally take on debt when it's useful to do so. I
also like his notion of minimum payments (which are very high to
fix issues with embedded systems as opposed to web sites).
Previous Topic
