This year, 2011, seems to have been the year of discussing, debating and, hopefully, dealing with debt crises. The U.S. Congress’ Super Committee has its deficit reduction recommendations due in three weeks. Meanwhile the Greek government is reconsidering the debt restructuring deal it signed just just last week. It’s pretty clear that in those situations, debt crises have reached a tipping point, but it’s far from clear whether those responsible will “man up” and address them.
It's with these current events in mind that I read Ilya Bagrak’s post Tuesday calling technical debt “a rabbit hole that goes deep, really deep…” This, combined with seeing Malcolm Gladwell quoted somewhere, made me ask myself – is there a technical debt tipping point? Is there a point up to which technical debt must be "paid down?"
Yes, I think there is, but like technical debt itself, it’s hard to identify and even harder to address.
We have defined technical debt as “the cost to fix the structural quality problems in an application that, if left unfixed, put the business at serious risk.” To figure out if there’s a technical debt tipping point and if so, what it is, we have to understand the definitions of “cost” and “risk.”
Cost can mean many things, including the monetary cost to bring in new developers to pay down technical debt, the physical and emotional strain of the extra hours to improve, refactor or otherwise improve code, and actual lost sales to customers and impact on the lead pipeline, to name just a few.
And what about risk? Risks can range anywhere from the inability to complete the product, losing talented programmers, falling behind competitors, damaging the company’s reputation, again, just to name a few.
But where does the tipping point of technical debt become so great that it causes irreversible harm, or as Malcolm Gladwell defines it, “the moment of critical mass, the threshold, the boiling point?" What’s scary is that a tipping point can result from activities with non-intended consequences. When the New York City Police began their zero tolerance campaign against petty crime, such as avoiding subway fares, it wasn’t part of a larger strategy to reduce violent crime. The goal was simply to reduce petty crime. Yet success with thwarting petty crime turned out to significantly reduce violent crime.
And that makes me ask, "What are IT activities that could cause the unintended consequence of going over the technical debt tipping point?" Is it a delay in product delivery? Is it customers backing out of sales and then a couple of developers resigning over concerns for the company and sparking an ongoing exodus of customers and staff? Or, is it a competitor announcing a market-changing new product, causing critical members of a development team to jump ship and resulting in a new product being late further angering loyal customers?
Another contributing factor to where a technical tipping point exists lies with customers themselves. After several lean years, many are competing fiercely to stay in business and the last thing they can afford is an IT provider that fails to deliver. These customers are also aggressively searching for a competitive edge and if they find new IT solutions that replace existing capabilities they will bolt in a flash.
But don’t get me wrong, technical debt is here to stay and, in some circumstances, is even necessary. For example, if it is known in the industry that a new solution will soon be available that will improve the process or the code on which you are working, there's little reason to rush and expend today’s less efficient resources.
But, in my travels, I see far too many companies that don’t have a handle on their technical debt. Far too many treat their technical debt like those in the financial sector who instigated the banking collapse of 2009, preferring to act like the debt doesn't exist rather than addressing it and paying it down to a healthy point. Just like Lehman Brothers discovered with their debt, technical debt left unaddressed will eventually take you down.
That doesn't mean every last red-cent of technical debt needs to be addressed. CIOs and heads of application teams should use automated analysis and measurement to evaluate the structural quality of their three to five mission-critical applications. As each of these applications is being built, they can measure its structural quality at every major release. They should also measure their structural quality every quarter after the application software is released.
From there, they need to keep a watchful eye on the violation count; monitor the changes in the violation count and calculate the technical debt of the application after each quality assessment. As shown in the diagram, once a dollar figure on technical debt is ascertained, compare it to the business value (For a framework for calculating the loss of business value due to structural quality violations, we recommend, “The Business Value of Application Internal Quality” by Dr. Bill Curtis.) to determine how much technical debt is too much and how much is acceptable based on the marginal return on business value.
With this formula, IT managers may be able to embrace 2011 as the “year that we started to proactively manage our technical debt.” It doesn’t roll off the tongue as easily as "2011, the Year of the Rabbit," but the benefits will "hop" off the financial ledger and pay dividends in the long run.