Breaking Down Technical Debt

IS YOUR CODE AN ASSET OR A LIABILITY?

In 2016, it would be impossible to have missed the technical debt renaissance that’s continued to build momentum over the last decade. But, like any metaphor, we must understand it in context.

Recent studies suggest that an average technical debt of $3-5 exists per line of software code, or an average of $1 million per system. In 2010, Gartner famously estimated the worldwide technical debt at $500 Billion, forecasting growth to $1 trillion by 2015. Over the course of this multiple-part series, we’ll level-set on exactly what technical debt is and explore how many quantify that debt: by line-of-code analysis, by management philosophy or business impact, or via other abstract terms. Further, we’ll look at the larger picture of how we often mistake the root causes of debt while attempting to quantify or define its financial impact.

As we review the core concept of technical debt, we’re not here to add another layer of complexity to the ocean of references and metaphors; rather, we’ll begin by refreshing the basics.

DO YOU KNOW THE TRUE VALUE OF YOUR SOFTWARE? ARE YOU SURE?

Ward Cunningham, a key contributor to the Agile Manifesto, once said that “Some problems with code are like financial debt. It’s ok to borrow against the future, as long as you pay it off.” 

The core concept of the metaphor Ward coined identifies a serious problem that many teams are struggling to manage—regardless of disagreements about the exact definition of technical debt.

First and foremost, though, technical debt is a metaphor. While it represents a very real phenomenon and continues to gain momentum, it does not, however, map neatly onto the notion of financial debt. Financial debt is always quantifiable in terms of its current cost and behavior over time.

Despite the critical need to quantify debt, it’s crucial to recognize that technical debt is not always quantifiable—not in all its forms and not always in a way that we can calculate or articulate. We also must acknowledge that this disparity doesn’t point to immaturity in the development of the concept, but a fundamental difference between technical and financial debt. Ward Cunningham has recently acknowledged this conceptual gap.

FINANCIAL DEBT HAS ONE FORM: MONEY OWED

As a working definition, technical debt represents the effort required to fix problems that remain in the code when an application is released; that is, the hidden costs associated with a system’s architecture and codebase. For example, changing requirements addressed with “quick fixes”, bugs deferred in favor of new development, design weaknesses, or aging third-party libraries are all commonplace examples of this type of debt.

When taking short cuts and delivering code that is not quite right for the programming task of the moment, a development team incurs technical debt. This debt decreases productivity. This loss of productivity is the interest of the technical debt.

Using debt-to-line-of-code analysis to estimate financial impact, while imprecise, does offer reasonable order-of-magnitude estimations. Group analysis is given to be even less accurate especially given that agencies like the federal government build and maintain massive amounts of software.

With an associated cost, however inexact, technical debt is a crucial factor in real-world decisions. Acquiring a company with a desirable technology, for instance, hinges on the long-term prospects of that technology. Those prospects are, at times, fatally hindered by crippling technical debt. Even when acquiring talent, valuation must be based in part on the debt they built, or better yet, the lack thereof.

Similarly, an organization buying into a platform needs to not only properly fund that initiative but partner with an outside entity. If that platform is laden with hidden debt, it will be prohibitive to maintain and upgrade. When technical debt isn’t understood or accounted for in situations like these, it can surprise all levels of stakeholders. This added burden leads not only to increased expenses and decreased profits, but also product delays, lost revenue, and a weakened competitive position. Significant value can be lost, and value creation opportunities missed, due to the failure to identify technical debt up-front, or partner to successfully mitigate it in the long-term.

Technical debt doesn’t accrue simply because of poor code quality or design. Often, it’s the result of a series of necessary decisions made over time—actions individually justified by their immediate ROI or the needs of a project.

After refreshing our background on technical debt, we’re ready to examine the path to building technical wealth. In the next installment of our multi-part series, we continue by highlighting current types of technical debt, the realities of quantifying that debt and the limitations therein, and the philosophical shift necessary to build technical wealth.

THE PATH TO TECHNICAL DEBT CAN BE PAVED WITH GOOD INTENTIONS…

But that doesn’t mean it can be ignored. Partnering with a flexible organization who examines your situation through a technical and business lens is crucial.

Apexon employs nimble, business-aligned delivery models to innovate, fulfill unexpected requirements, and ultimately partner to drive operational results for your business.

Want to learn more about Apexon? Consult with an expert here.