If technical debt is an inevitable part of every software project, why aren’t developers routinely given time to resolve it?
There is the concept of the iceberg of ignorance, which states that the further up the organisation hierarchy you go, the less aware management are of front-line problems. According to a study, if front-line workers (i.e. developers) are aware of 100% of problems, team leads are only aware of 74%. Their own managers are only aware of 9% of problems, and executives at the top of an organisation are only aware of 4%.
Regardless of whether you believe those specific numbers or not, the idea is that people at the top of an organisation are simply not aware of the kinds of technical debt problems that developers are routinely dealing with. Why would they be? They have broader concerns than that. If my CEO had opinions on whether we should refactor some particular piece of code, that would strike me as very worrying and weird.
So, the problems caused by technical debt rarely bubble up to the higher levels of the organisation - which means that they’re not going to treat it as a priority.
Technical debt is also rather hard to measure. In a previous section we talked about the debt analogy, where the “principal” is how long it’s going to take to fix a piece of technical debt. Unfortunately, we tend to be pretty bad at making estimates, which means we often don’t really know how long a given piece of technical debt will take to fix. The “interest” in technical debt, which is how much the debt is costing us to maintain, is also hard to measure. We would need to have some way of measuring how much that piece of technical debt is affecting productivity. But how do we measure productivity? It’s well established that measuring things like “number of lines of code written” is a pretty dreadful way of measuring the productivity of developers - and nobody seems to have come up with anything much better.
In very important ways, technical debt is not like financial that at all. If a company wants to take on financial debt, there are lots of processes and controls in place. That’s not the case with technical debt - an organisation can hardly see it or measure it, and there are rarely many mechanisms in place to stop it from piling up unchecked.
So you will never just be given time to fix it, and the only way that you’re going to get time to fix it is to make a case for it. And that means persuading human beings, and that’s what we’ll look at next.