(^2) 97 Things Every Programmer Should Know
Whatever you undertake, act with prudence and
consider the consequences.
NTTERO MA 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.