Technical debt is hard.
It’s hard admitting that technical debt even exists. Admitting it exists means that you’re admitting to maintaining code you’re not proud of. It may not be code you’ve written, but on the other hand it may very well be. Part of growing is learning, part of learning is to recognize that what you’ve done before could have been done better.
Admitting its existence is nothing compared to reducing technical debt. Over a couple of decades I’ve come to wonder if this isn’t the most difficult task facing a software engineer. There are so many obstacles to it, making any serious headway can seem insurmountable. Your Product Owner may not be taking into account time to address technical debt when making schedule targets, so it’s hard to get the work on your scrum board. The organization seems always ready to say that the next feature is critical to customer retention and/or acquisition and must, for now, be a higher priority. The customer seems always ready to walk away if you don’t deliver their widget of the day (or hour) within a ridiculous time frame.
And so initiatives and plans are created, and it seems the more technical debt there is, the less likely it is to be prioritized. There’s so much of it, after all, that it could be months before there is any measurable gain from it. Months of customer churn and declining revenue, months when maximum value is not being delivered to the people who ultimately pay our salaries.
It’s hard to persevere. No one argues that reducing technical debt isn’t important. But it never seems to be the most important. Something else always takes priority, because it’s easy to point to dollar signs directly connected to the widget of the day.
Overcoming Organizational Impediments
But we must recognize this resistance for what it is: organizational impediment. There is a structure, organizationally, firmly in place that is impeding our progress on this critical area. It’s all the more important, then, that we as software professionals hold the organization accountable. We were hired because we are experts, and we rightly have an expectation that our input on software is taken seriously.
It’s tempting to hold the organization’s feet to the fire by forcing the question, with every new plan, every new initiative, every new effort to reduce customer churn: “How does this plan reduce technical debt?” If there is no answer, or if the answer is that it’s just being delayed and we’ll get to it with the next initiative, what are we, as mere software engineers, possibly able to say to our CEO or CTO?
Perhaps we’ve just asked the wrong question to begin with. Instead, let’s phrase the question a bit differently: “How does this plan address technical debt?”
Similar question, but enormously different implications. Everyone needs to understand that technical debt will be addressed. It will either be reduced or added to. Choosing to do nothing is choosing to add. What are the consequences of this choice?
Addressing the Consequences
Most importantly, a consequence is we will always have customer churn. Technical debt slows the project down, and the more of it that exists, the greater the drag is. It means that fewer and fewer changes can be made without risk, and more and more effort needs to be put into the act of manually checking for risk. And more and more missed discoveries of where risk is realized, until the customer finds it.
Then work flows backwards, with expensive resources asked to go back weeks or months or even years in the past to address a code defect that must take priority over all other work, because a patch is needed next week at all costs. That means valuable engineers are not spending their time doing the next feature the customer demands. And the customer demands it in a ridiculously short period of time or they’ll go elsewhere…and thus churn continues, and technical debt takes the back seat, and the cycle begins anew.
It’s our responsibility, as software engineering professionals, to make the case clearly and cogently to the organization that no initiative will achieve the desired result if it doesn’t include reducing, not just addressing, technical debt.
What approach does your team take to reduce technical debt? How has it been received in your organization? Join in the conversation below or Contact Us.