Discussions in the industry about technical debt have been focused on the IT costs involved in remediation and the potential risk to the company if applications deployed with poor structural integrity fail to perform optimally, or fail completely.
But some impressive new ways of looking at the cost of technical debt as it relates to a company’s market capital were revealed last night during a dinner hosted by ThoughtWorks and CAST. Titled, “Technical Debt: Issues and Financial Implications” Jim Highsmith, Executive Consultant for ThoughtWorks and Jitendra Subramanyam, Director of Strategy and Research for CAST, presented a two pronged approach to the issue of technical debt in the agile corporate environment—the financial benefits of reducing it and the ways to reduce it—aspects that can help IT management convince product management that focusing solely on delivery speed can cost the company more than developer headaches.Highsmith provided insights into why technical debt is a strategic issue beginning with a look at agility. Citing a report by The Economist Intelligence Unit, he pointed out that over 88% of executives surveyed cited organizational agility as the key to global success and that, one-half of all CEOs and CIOs say that agility is not only important, but also a core differentiator. Perhaps more astounding is that, according to findings from the MIT Sloan School of Management, Agile businesses have a huge “Return on Agility”: 29% higher earnings per share; net margins at over 20%; the return on assets are greater than 30%; and revenue growth is a steady (always important to Wall Street) 8% or more.
Highsmith was quick to point out, however, that the buildup of technical debt over time can bring the gears of a smooth running agile business to a screeching halt. At some point, delivery speed and customer responsiveness start to drop exponentially. Once you’re headed down that path, all choices become bad choices – do nothing, and the problem gets worse; replace with high cost and high risk; or make incremental investments that can consume resources. Whether it is scrambled code, poor test automation and coverage, outdated architectural components, multiple code pipelines, outdated infrastructure or poor build management and configuration control, these sources set the stage for production of a mountain of technical debt unless you work to strip it out as you continue your agile development.
Unfortunately, one of the biggest problems is that technical debt is somewhat fuzzy and intangible, so management can have a difficult time dealing with it. That’s the bad news. The good news is that “fuzzy and intangible” is the stuff of which great market capitalization is made.
According to Ulrich & Smallwood in “How Leaders Build Value,” in 1982, the impact of intangibles was only about 38% of a company’s market value. By 2000, that number had risen to a staggering 85%. Brand equity, corporate reputation, company innovation do not appear on a balance sheet, nor will they in the future. But “it’s the software, Stupid,” to paraphrase a well known phrase, that is the underlying structure keeping these intangibles on the rise…that keeps market capital on the rise.
The cost to repair that software has become a huge source of corporate cost. The potential for reduced revenue based on delays or market opportunities that aren’t captured because of it are significant. The effects on brand equity or corporate reputation when software applications fail are huge. These are not cubicle issues; they are board room issues.
Management has to think about the fact that their business is truly in the hands of application software. Left alone, the causes and the impact of technical debt can leave those hands so dirty they lose their dexterity. In some instances, they can become immobile. And idle hands are the Devil’s…well you know.