not have significant impact on the usability or long-term maintainability of the final system. Very few systems have no TODO or FIXME or XXX comments somewhere in the source code. Note that the cost of paying back technical debt comes in the form of the engineering time it takes to rewrite or refactor the code or otherwise fix the problem. If the interest you ultimately accrue is less than the cost of paying back the debt, there is no point in paying it back in the first place. The problem is that it can be difficult to know in advance which debts will ultimately have the highest cost.

For example, when U.C. Berkeley’s CalMail system went down in November 2011, the problem was traced to deferred maintenance—in particular, the decision to postpone updating the system even though it was known to be near capacity. 5 One disk in a RAID died, shortly followed by a second, and the cost of rebuilding the array reduced capacity sufficiently to create a crisis. Murphy’s law needs to be taken into consideration when deciding how much technical debt to accept. In the CalMail case, individual hardware failures were expected in the base design, but multiple failures, happening during a historically high usage spike, created a condition that was not quickly resolvable. According to Berkeley’s associate vice chancellor for information technology and chief information officer, Shelton Waggener, “I made the decision not to spend the million dollars to upgrade CalMail software for only 12 months of use given our plan to migrate to new technology. We were trying to be prudent given the budget situation, (but) in retrospect it would have been good to have invested in the storage upgrade so we might have avoided this crisis.” This is a case where technical debt was taken on intentionally but turned out to be a bad gamble. Had the system survived that 12-month window, the school likely would have saved $1 million during a budget crunch.

There is a saying to the effect that
there are three variables in engineer-
ing: time, functionality, and resourc-
es—pick two. In fact, there is a fourth
variable: debt. Of these four variables,
you can set any three of them, but you
can never set all four; something just
has to give, and very commonly debt is
the free variable in the equation. Debt
can seem “free” at first, but technical
debt tends to build on itself. If the ac-
quisition of debt involves interest in
the form of increased effort to main-
tain and extend the system, then as you
take on debt it gets harder and takes
longer to do maintenance and exten-
sion. This is one form of collapse un-
der debt: if all of your “income” (in the
form of effort) is spent paying off in-
terest and nothing is left over to move
the system forward, then that system
is stuck. This is especially obvious if
productivity is measured in lines of
code produced per day, a measure that
should be relegated to the fires of hell.
You do not have many choices left: add
effort (hire more engineers), abandon
the system and move on, or go bank-
rupt. In this sense, the interest on tech-
nical debt is actually compound inter-
est, or put another way: if you don’t stay
on top of the debt, then the payments
go up over time.

 

managing your Debt Technical debt is inevitable. The issue is not eliminating debt, but rather managing it. When a project starts, the