On Technical Debt - I

Andy Lester was in town last week, and he did a wonderful talk on technical debt.

Andy's main point seemed to be that technical debt (like real debt) is a drag on the project. By taking shortcuts today (in documentation, or coding, or skipping tests - or cutting and pasting when we should be generalising) we create the appearance of progress, but slow down future progress.

Eventually, even small maintenance tasks take a tremendous amount of effort, not because the work is complex, but simply to pay off the interest. The customer "just" asks for one change, but it has to be implemented in fifteen places, and the code is hard to understand and wacky, and no documentation exists.

Andy even presents a "five step plan" to pay off the debt, much like any "real" debt reduction plan.

But I'm disappointed in just one way: I didn't see any talk of the root cause of technical debt. There must be one; pressure to meet deadlines (and the skipping of corners that tends to entail) seems to be universal.

Until you address the root cause, I suspect that any "technical debt reduction" plan will fail.

To understand how "technical compromises" happen, let's take one example.

I (Matt) am under pressure to hit a deadline.

If I cut a corner, and do a "bad job", I will still hit the deadline - a Positive, Immediate, Certain result. If there is any NEGATIVE result, it is uncertain, out in the future, if ever.

If I do it "right", I will miss the deadline. I could get a lecture from my boss, the customer, or both. I may be written up for not being a "team player" on my annual eval. That is negative, certain ... and immediate.

Behavioral Psychology tells us that positive rewards are more powerful than negative. It also tells us that immediate rewards are more powerful than delayed. Finally, it just makes sense that certain rewards are more powerful than uncertain.

Which may explain my (slight) weight problem. A mountain dew will TASTE really good *right now*. It's positive, certain, and immediate. Not only that, one single drink won't make me fat. Yet the combination of those choices, over time will certainly make me fat - and habitually fat, to boot.

In software, the bad choice is the clever hack, done without improving the design. The extra if () { } block thrown around the code. Cruft. Files hanging around that should have been deleted last month. One or two or these won't kill you - in fact, they may certainly be a short-term gain. But a dozen? A hundred? A thousand?

It doesn't take a genius to figure out why shortcuts happen in code: The incentives are misaligned, just like weight gain. Unless you do something to change those incentives, exhorting the team to "Do The Right Thing" will be just more cheerleading, like "Zero Defects" was in the 1990's and "TQM" in the 1980's.

How can we change those incentives?

Let's talk about that next time.