We left Part I with two questions on the table:
- Is there no way to say anything quantitative about tech debt?
- If tech debt is as corrosive as we think, and few if any enterprises are managing it intentionally, how can any company thrive? And. They. Do. Thrive. Wassup wid dat?
Another swing at a quantitative approach
I’m not ready to give up on a quantitative assessment of tech debt, so let’s take another swing. I really do think it’s that important. So here is how I propose we think about technical debt. A healthy technology stack is one that is generating revenue sufficient to pay for its operational cost and the incremental cost of forward changes needed to keep it in that competitive position. Incremental cost of change is something you can measure straight-forwardly because it’s visible over short horizons without unreasonable assumptions about the future. Quantifying the incremental value of change is less straight-forward. And we really do need to get to a cost of value delivered, not cost of effort. If you will allow me to put a pin in that gaping hole for a moment, I want to finish sketching in the arc and then we’ll come back to it.
Given an incremental cost of value over short runs (e.g. – projects) we can track changes to that over long runs. Notice that this gives us a rate of change of a rate of change (analogous to acceleration). Huh – an acceleration in our cost of value. Or, holding cost constant, a deceleration in our ability to produce value. Ponder that for a moment. That resonates with how I think of quality, and the impact of technical debt. I don’t mean quality in the sense of the suitability of the technology stack for a particular purpose. I mean it more in the sense of the integrity of the tech stack. Furthermore, I don’t really need to assign meaning to any absolute scale of the cost of value or the acceleration of value. That is highly contextual. I just need to know if the cost of value is meeting my needs for the things I want to do next, and I need to know if it is trending in a direction that would eventually threaten that.
Now this is starting to look interesting. So, we really need to get at that notion of how to quantify value. First, a caution. You might be thinking the cost of value is necessarily related to the Agile concept of velocity (and you would be correct). However, I am a big believer in keeping that metric unitless (mostly) and sacrosanct for short term team planning. It is a way to predict how much a team can get done over limited horizons and should be left alone as such. What is needed for our present exercise only needs to approach project level granularity and needs to capture some notion of value. A thorough treatment of this is beyond the scope of this already long article but if you type “function points” into your search engine you should get some food for thought. But I don’t think we need anything that complicated. I think “good enough” is achievable and I would approach it along the following lines. Something simple, like “lines of code”, could be good enough. No doubt you can come up with objections but don’t be hasty. It should be clear that this is an objective measurement that for a given technology is reasonably well correlated to functionality on statistically meaningful samples. Another possibility is to measure the complexity of the requirements required to adequately scope the work. In a world where we try to make our stories small, this could be as simple as a count of the number of stories it took to do the work by the time it was completed. This does assume we are in the habit of writing good stories… or that we are at least consistent in how we write bad ones. If I had my druthers, and a reasonably consistent practice of good story authoring, I would go that route. It’s more independent of the technology. Otherwise, I would mine the code for metrics, like lines of code, to capture proxies for the amount of functionality produced. Nothing will be perfect, but we really don’t need perfect. We need directional. This might be enough to give us an objective and straight-forward measure of “cost of value” and “acceleration of value”. And it can be harvested from artifacts that most organizations already have… even on a historical basis. While this needs further development, the approach seems both pragmatic and fruitful.
Now we have a framework that could give us some insight into the relative impact tech debt is having on our tech stack over time. How you set about reducing tech debt is not the subject here and I don’t think the means for doing so are particularly controversial. What is always controversial is the value of doing so. The real challenge is to help stakeholders understand that ignoring tech debt is not an option. Unless it is…
Why haven’t we all been sunk by tech debt?
If companies routinely thrive without being very intentional about this, do I even need to bother with all that stuff from the last section? Can I just not care? Oh please, please, tell me I don’t have to care. No. I think you must care. But… and it’s a big “but”, let’s step back even further and try to frame this. I do think it is managed – but not with intentionality.
If you at least accept that tech debt is corrosive, it would be possible to manage simply by being obsessive about not incurring it. This is just a way of not having to remember how much you owe Sven and Ole by not going to that well. In applied mathematics (physics, engineering, etc.) we often try to reduce a term in a complex equation to something as close to zero as possible so that we can just ignore it and simplify the equation. It has the benefit of giving the equation greater explanatory power. Certain simplifying assumptions are enabled if you can hold certain conditions true (much the way a condition of statelessness allows a process to be killed, spawned and scaled with relative ease). You might be able to happily declare “the secret of our rapid ability to adapt is that we are fanatical about not incurring tech debt”. Do I think anyone is doing this? Don’t make me laugh. Certainly, I haven’t seen it. But I am fond of the idea that there might be a few oases out there somewhere. And, paradoxically, it could be a mistake to fixate on tech debt in some circumstances. When do you take out a mortgage with a balloon payment? Well, I don’t even play a financial consultant on TV, but generally you do it in an inflationary housing market when you don’t plan to own the house long enough for the balloon payment to come due. Frankly this makes me squirm, but it would be a mistake to suggest that my risk tolerance should dictate everyone else’s. So, let’s look at this because I think it comes closest to explaining what we actually observe.
If tech debt drives a deceleration in your ability to deliver value it implies your technology stack has something like a half-life. This would be the time over which its ability to maintain or generate new revenue potential is cut in half. It doesn’t really matter whether this is being caused by software rot from poor practice, or simply because the competitive and regulatory landscape is changing, and your stack is aging out. The greatest asset you have in combating it is the ability to change and change quickly (which is what tech debt directly attacks). What kind of numbers are we talking about… three years, seven, ten? And what is the result if it’s not addressed? A dot bomb? A business that is not worth as much as the balance sheet suggests? Here’s a thought. What if one way to make tech debt drop out of the equation (or treat it like a constant) is to bake in the cost of a complete refresh of the technology stack every seven years and use this as a baseline to determine if revenue expectations are sufficient to maintain the technology stack? I was kicking something like this around with an associate recently and it seemed not entirely crazy. Just assume worst-case tech debt and see if financially you can swallow the reductio. It’s a bit like having a stateless server with a memory leak – you can just reboot it periodically rather than trying to properly manage memory. You don’t worry about how much you owe Sven and Ole because when they come knocking your revenue expectations allow you to offer them double or nothing on the next round. I don’t know if seven years is reasonable, but this is a thought experiment, and it doesn’t seem unreasonable if you’ve gotten where you are by running fast with knives.
Should anyone actually bank on this as a strategy? It’s one thing to jump out of a plane when you have a parachute, but I just know there is a certain kind of person who will assume they can acquire a parachute on the way down. Still… it seems to have a great deal of explanatory power about the last few decades in this industry. I think it likely that the companies that have survived, have done so by overwhelming their tech debt with growth. They have the tiger by the tail, and they refresh the tech stack because they can’t scale the existing stack any other way. If the revenue stream supports the growth and they can pull it off, three cheers. Are they the exception that makes the rule? I certainly think we have had (past tense) our fair share of those that are the rule. Is anyone successfully treading the middle ground? I have observed several enterprises that find themselves in this middle-ground, but I don’t’ know if they are successfully navigating it. I am tempted to say that they are going down slow while looking for a way to break out into the high-growth zone. If any of them manage the trick of thriving in the middle, they will be the ones who realize they can’t rely on insane growth to bail them out but also recognize the enervating impact of tech debt. Having the tiger by the tail and, faced with losing their grip, they will manage to climb on and ride the tiger by getting intentional about tech debt. I am emotionally invested in this being possible – I don’t want the business landscape to divide into the two poles of “insane growth” on the one hand, and “failure” on the other.
But you object, “you said there would be tweetle beetles”. Indeed, I did. And I would suggest you have two options for how to deal with tech debt. Either you gird up your loins and prepare for a
muddle puddle tweetle poodle beetle noodle bottle paddle battle
Dr. Seuss, Fox In Socks
or like Knox you proclaim
Fox in socks, our game is done, sir. Thank you for a lot of fun, sir.
Dr. Seuss, Fox In Socks
I guess I’ll let you decide which approach is which.