|
Debt would be if someone said "I need to build a bridge across here that can handle an Army, and I've got $1m", we engineers reply "It will take $2m", and they respond "Ok, I will borrow $1m so you can build the bridge I need". Instead what happens is they say "Well, build what you can for $1m", and you say "Ok, we can make 'a bridge' for that", and then either (a) your infantry can cross, but the tanks have to get diverted 20 miles out of the way, or (b) the tanks end up in the river along with the bridge. Since (b) is bad, you then have to spend a lot of time planning the routes for the tanks, and making sure the tanks have the right air cover, etc etc, i.e. doing more work. More likely, however, is that the manager, who is not a structural engineer, sees a perfectly good bridge and orders the tanks across anyway, causing the loss of the bridge, the tanks, and the war. It's not debt. It's just (at best) an incomplete solution or (at worst) a bad solution that fails at the worst possible moment - e.g. database collapses during registration for the largest event of the year. Ah, but surely, if you build the lightweight solution for $1m, and acknowledge the increased costs of managing the problems that it doesn't solve, then thats fine? Sure, but that's not technical debt either! That is scoping: we (engineers + business) identify a workable solution that provides some business value. And then we do that well. When Cunningham, for example, talks about what to do about debt, e.g. YAGNI, these are all good ideas: scoping. But the term "debt" is incorrect in this case. The term "debt" will only ever get a team in trouble as it indicates that the team is unwilling to confront the actual problem as engineering, but only as a broken metaphor. |
Well, those are two possibilities, but a third is that you don't need it because of one of several possible reasons.
The debt metaphor still fails to hold up; the nice thing about accepting "technical debt" into your project is that you may never come upon a time where it needs to be paid off at all. Not all tech debt must be paid off.
Usually only the highest priority tech debt can actually be paid down, and it doesn't always come with an interest cost. But when it starts to "come due," if you're an engineer in the hot seat, you can often (usually) tell pretty quickly just how much the "interest payment" actually affects your ability to deliver future iterations.
Your "customers" or stakeholders can tell too, indirectly, when your estimates start outpacing their "very reasonable expectations."