The idea of technical debt has become ubiquitous in our industry. It started as a metaphor to help business stakeholders understand the compounding cost of shortcuts in the code. Then, from there, it grew to define perhaps the foundation of trade-offs in the tech world.
You’d find yourself hard pressed, these days, to find a software shop that has never heard of tech debt. It seems that just about everyone can talk in the abstract about dragons looming in their code, portending an eventual reckoning. “We need to do something about our tech debt,” has become the rallying cry for “we’re running before we walk.”
As with its fiscal counterpart, when all other factors equal, having less tech debt is better than having more. Technical debt creates drag on the pace of new feature deliver until someone ‘repays’ it. And so shops constantly grapple with the question, “how can we reduce our tech debt?”
I could easily write a post where I listed the 3 or 5 or 13 or whatever ways to reduce tech debt. First, I’d tell you to reduce problematic coupling. Then, I’d tell you to stop it with the global variables. You get the idea.
But today, I want to do something a bit different. I want to talk about the one thing that every company can do to reduce tech debt. I consider it to be sort of a step zero.
The Tale of the Absent Product Owner
But before I go for the big reveal, I’d like to veer into a bit of a parable. Don’t worry — I’ll try to make this at least nominally entertaining via the art of the narrative.
Once upon a time, during my travels as an IT management consultant, I encountered a team looking to improve its throughput. Okay that might describe every team I work with, so I’ll get a bit more specific. This team wanted to improve throughput, but found itself stuck when it couldn’t get answers to clarifying questions about the business quickly enough. “Should we consider user submitting an invalid form an error state, or do we expect that?” Crickets.
This team had “gone agile” at some point. From there, they worked their way into a comfort zone with this new reality, adapting to the roles and ceremonies of a Scrum team. One such role, the product owner, serves to represent the business to the team. But with this particular team, the product owner seemed in a constant state of attending meetings in other locations, away from the team.
How did they fix this? Meetings? Interventions from on high? Pleading? Nope. They went more low tech and simpler. They simply started writing on a big white board, “number of hours with access to the product owner today” followed by the count. The whole department could then see that this team had access to its product owner for 0 or 1 hours. With no other interventions whatsoever, the number increased significantly within a matter of weeks.
Sunlight is the Best Disinfectant
I had no shortage of management consulting cliches from which to pick for this section’s header, but I went with words of Louis Brandeis. I just like the ring of it.
Sunlight makes the best disinfectant. This colorfully illustrates the notion that simply illuminating problems can make them go away. In this case, calling the product owner’s (and everyone else’s) attention to his rampant absenteeism inspired him to address the problem without further prompting. You have probably experienced a phenomenon like this in your personal life. For instance, perhaps just the act of weighing yourself every day makes you lose a bit of weight, simply by virtue of putting the effects of your eating choices in the front of your mind.
Generally speaking, focusing the spotlight on something can, in and of itself, alter the thing you’re looking at. We might borrow from physics and think of this as “observer effect.” It packs a powerful punch as a recommendation because of both its inevitability and potential healing power. If you want to improve something with any efficacy, you must first start measuring it so that you have a benchmark.
Thus shining light on something represents a possible improvement strategy in and of itself, as well as a first step ahead of other interventions. It is for this reason that I think of measurement as “step zero.”
Back to the Topic of Tech Debt
The recent release of NDepend reminded me of this question that organizations often ask me about tech debt. They want to know the single best approach for mitigation, and NDepend’s new release offers it in spades.
Simply put, you can best fight tech debt by visibly measuring it. Do you need to get the exact number of hours or dollars spent on employee labor completely correct? No, of course not. Don’t get too hung up on that.
Just go put a figure to it so that you can watch that figure change as you do your work. I cannot overstate the importance of this. If you wring your hands over the particulars, your tech debt will remain forever unquantified and thus abstract. If you say, “we have a lot of tech debt,” business stakeholders will answer, “so does every place I’ve ever worked — whatever.”
But if you write up on the big board that you have 225 days of tech debt when yesterday’s figure had only 200, people are going to notice. Discussions will start. Suddenly, the tech debt becomes everyone’s problem. And, once that happens, watch as the number starts to decrease as if of its own volition.