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” with 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 prob-

lems and you become focused on them. This sort of deferred work is known

as technical debt, and it is not your friend. Specifically, Martin Fowler calls this

deliberate technical debt in his taxonomy of technical debt,* and it should not

be confused with inadvertent technical debt.


Technical debt is like a loan: you benefit from it in the short term, but you

have to pay interest on it until it is fully paid off. Shortcuts in the code make

it harder to add features or refactor your code. They are breeding grounds

for defects and brittle test cases. The longer you leave it, the worse it gets. By

the time you get around to undertaking the original fix, there may be a whole

stack of not-quite-right design choices layered on top of the original problem,

making the code much harder to refactor and correct. In fact, it is often only

when things have got so bad that you must fix the original problem, that you

actually do go back to fix it. And by then, it is often so hard to fix that you really

can’t afford the time or the risk.


There are times when you must incur technical debt to meet a deadline or

implement a thin slice of a feature. Try not to be in this position, but if the situ-

ation absolutely demands it, then go ahead. But (and this is a big but) you must

track technical debt and pay it back quickly, or things go rapidly downhill.

As soon as you make the decision to compromise, write a task card or log it in

your issue-tracking system to ensure that it does not get forgotten.

(Source: )