Technical Debt is a single, simple, linguistic trick. It's the game where you make up a word for something where we never needed one. Say you have a project where you cut corners, and one where you didn't. What's the word for the difference between them? We get to make it up -- Technical Debt. It means "the units measuring corner-cutting". Fun, right?
Now you know everything there is to know about the complex new software engineering term Technical Debt. Everything else is people loving a catchy phrase.
For one, they can't resist extending a metaphor: skimping on code is taking out a loan to finish faster. The hidden shoddiness it creates -- that's debt. You pay it back by redoing the project the right way. And finally, the extra difficulty of working on a poorly designed product is like paying interest. As with all metaphors like this, it's for entertainment value only.
It's also fun to use a new word to claim things. Now we can list ways to get Tech Debt -- a list of reasons people cut corners. We can list types of Tech Debt, which is merely tasks commonly put off until later. But it's fun to pretend that we're discovering this, and seeing the world in a new way.
But there's a bad part. Metaphors can trick us. They can slide in an unexamined wrong idea, which is what Tech Debt does. Real debt only exists if it can be exactly measured. It exists on a single scale with a single absolute point where you owe 0 dollars. If programs are like debt, there has to be an agreed upon correct "no debt" program. That's not true. A serious discussion about a project can't possibly start with "OK, so here's the best way -- how much of this are we going to do, and how much will we owe for later?".
Suppose we read how one source of Tech Debt is waiting to upgrade to the latest version of some tool. Wait a minute -- since when is quickly installing every upgrade good? We should be waiting on them and skipping some. Likewise, not making a complete framework for a new feature counts as Tech Debt. But that's merely another way to say we should make a big framework first. That's not true. Not doing that is the point of Agile.
In a sense, "Tech Debt" is just a fancy way of claiming I know the right way, and you're doing it wrong. In fact, I'm such a jerk I have a special word for how wrong you are.
On a lighter note, Tech Debt is a backwards metaphor -- from familiar to unfamiliar. People know about taking shortcuts, I suppose, but to really explain cutting corners we need to use something they truly understand -- corporate finance. Tech Debt starts with: "you know how businesses only take on debt in emergencies and pay it back quickly?" No. But it's interesting that you think it.
Oddly, Tech Debt might be a useful phrase without all of the ink spilled over it. "TD" scrawled over three days of the schedule is clear enough -- working, but not on new features or bugs. That's all it needs to mean -- "a routinely scheduled period, part of development, when no obvious work gets done".
Comments. or email adminATtaxesforcatses.com