I am done with "technical debt" as a useful concept.
As so often happens, an appealing idea happened, one with useful connections to the concrete, and we took it and ran with it. Unfortunately, that idea has more appeal than it does decision-making value.
Folks justify the most ridiculous nonsense and put it under the heading of "technical debt". In particular, they write shitty code, I mean terrible code. They do this in the name of productivity. The claim is they are accruing technical debt, and that it’s just debt, and that they’re borrowing speed from the future to pay for it now.
Here are some problems with that claim.
First, it simply isn’t the case that shitty code now makes more features faster now. That is, you can not go faster by writing shitty code. So right from the get-go the metaphor breaks down.
If I borrow Y money it is to get X now. I borrow it, I get X now, and I pay back Y + Z. Would I borrow Y if I didn’t get X now? Ummmm, no. So first, you don’t get the thing you’re borrowing for. That’s one issue.
Second, debt in general, as my friend @YvesHanoulle just pointed out, is one of those "i’m good at it" things. People think they know all about debt. That, after all, is the appeal of the metaphor, right?
Do look around you, tho. Would any reasonable person say that the world is full of people who are good at debt? The idea that "i’m good at debt" is far more widespread than the reality of people being good at it.
So, too, with technical debt. The idea that "i am good figuring out costs+benefits for technical debt projection" is far more widespread than the reality. So second, technical debt’s appeal is actually based on a false premise, that most of us understand financial debt and manage it well.
Third, unlike financial debt, there are no tables charts and formulae to help us parse our technical debt. There are no numbers associated with technical debt. No numbers means no math. No math means analysis based on intuition.
And we’ve just pointed out in flaw #2 that — even with numbers — skill at parsing debt calculations is actually quite rare. Financial debt success — bounded by math — is rare. How much more rare is technical debt success — bounded by guess and supposition? So the third flaw: the non-mathematical nature of technical debt makes the successful management of it even less likely.
Let me enhance your terror a little, too, by pointing out that the technical debt decision makers don’t even have technical credentials. How likely is it that a middle-level manager who lives in meetings, powerpoint, and outlook, can assess the cost/benefit of shitty code?
So. For me, technical debt is just out the door. It fails on at least three points to be a compelling or useful metaphor.
I should back up a little, tho. There is something there, and we must consider it.
My friend @WardCunningham cut a video years back about technical debt, in which he explained he never meant for anyone to write shitty code. What it seems he was talking about when he first spoke of technical debt wasn’t the kind of awful crap we see today at all.
Rather, it was about deferred design decisions. In the hardcore XP mode we work largely without a big overriding design model. This notion is reflected in the idea of working by stories. We solve just the problem in front of us. We do not solve ahead. We do not even specify ahead. We take our challenge one story at a time, work that story to completion, and move on. This means that we are always, permanently, deferring the idea of "the once and for all best design for our finished app".
This idea, the "permanent revolution" if you will, lies at the heart of the modern software development synthesis.
We have been slow and awkward in bringing this notion to the fore. This is the source of many flaws in our current attempts to do so. Think about the story wars, the gradual rising attack on capacity-box planning, the usage of "technical debt" to justify shite code. All of this muddle comes from our failure to grasp and explicate the permanent revolution and its related concepts.
I’ll take a breather there. Thanks for letting me muse!