Making technical debt visible …

Making technical debt visible already proves to be quite a challenge, as it’s all about exposing the underwater part of the iceberg.

But how deep underwater does it go? To know for sure, you would need the right diving equipment. To go just below the surface, you would start with a snorkel. But to go far down, you need a deep-sea exploration submersible.

This is comparable to software. To know for sure how many issues you have under the hood, you need the right analysis equipment. Simple source code parsers help (like a snorkel). Finding cross-technology, cross-layer, system-level faulty patterns is another matter.

… to be sure that you do not miss the issues that matter.

Indeed, when looking at production defects with severity 1 and 2 level, that is, total stoppage and major disruption, studies show that 30 percent of these have a structural nature (Source: Capers Jones. Data collected from 1984 through 2011; 675 companies (150 clients in Fortune 500 set); 35 government/military groups; 13,500 total projects; 50-75 new projects per month; Data collected from 24 countries; Observations during more than 15 lawsuits.)

Looking at other severity levels could be interesting, but that would distract us from driving the point home with non-IT people.

Technical Debt is such a "beautiful" concept because it’s:

Technical debt appears to be perfect, but …

It turns out that in many cases, after an initial success, technical debt assessment can be, at best, useless and, at worst, counterproductive. How come?

... Is it even useful? Is it helping?

It does have some tough challenges ahead:

Among the many challenges are:

The unsettling propensity that the technical debt principal sum could increase without updating the application, which goes against the traditional notion of financial debt. Financial debt can increase over time because its principal sum increases and because the interest rate kicks in. But it cannot increase simply because you are changing the tool or the capabilities of the tool to measure it. If the amount of the technical debt can fluctuate that much, how serious is it?
The “shock and awe” caused by communicating the sheer amount of technical debt, especially when it starts to be much greater than the estimated price of the application.
The helpless state managers are left in when it comes time to repaying the debt. With financial debt, some debt is better kept un-repaid as the money will yield better return if used to invest.

What is missing from this picture?

Look at the fine print …

With financial debt, what really matters is found in the contract’s fine print. What are the penalties associated with a default on the debt payment? What the interest rates? How do they evolve when you have already defaulted once or multiple times?

Up until now, we have only considered the principal sum of the technical debt. Nowhere have we found a reference to its fine print.

Making technical debt more useful …

As for personal and corporate finance, using debt structure helps.

Financial debt management is not trivial. However, the financial world is equipped to deal with it. They do this, quite simply, by structuring the debt.

Using interest rates and fees, one can decide:

Which part of the principal to repay and which part to keep as is (E.g.: debt with no or very low interest rate can be kept for as long as one wants. Repaying this kind of debt tomorrow will not cost more than repaying it now, maybe even less if one accounts for inflation).
Which one to start with, assuming that you might not be able to repay every part.
Which part is considered as toxic? In the software development and maintenance area, there are more opportunities to turn toxic. For example, the inability to port an application onto a new release of a mobile OS is simple technical debt and no issue at all if there are already plans for a new application development to support the new release. But it can be a catastrophe if the market adoption for the new release is massive. Your users won't be able to use the application, and you won’t have any alternative at hand.

Interest probability…

Interest rates and fees cannot be accurately computed ...

With software, it is impossible to accurately compute interest rates and fees, let alone the toxicity of some technical debt. It is highly context-dependent and related to the business purposes of the software. Is the software mission-critical for the organization? Does it handle sensitive data that would irreparably damage the organization's image and business if leaked? Does it feature an online, customer-facing front-end? If you answered any of these questions with a "yes", then interest rates and fees must be pretty high.

How high would that be? It’s difficult to tell until it happens, but then you’d know the financial impact the issue had. At that moment, saying "I told you so" isn’t really helpful. So let's be more constructive than that.

... but interest probability can be estimated.

The software code and structure will never tell you about the actual consequence of any single issue. But they can tell you a lot – automatically, provided you are equipped with the right gear.

That gear will help a lot to enable you to know if the severe stability, security, performance, adaptability, or analyzability issues are located in:

A massively shared component
A component used in a mission-critical, user-facing transaction
A normal component

How does it help? It estimates the probability of the issues kicking in and starts collecting the debt interest.

For example, a performance issue detected in the cache management layer of an application was able to bring the whole application to a halt because a single component was being used by virtually every component of the application.

All transactions using an unsafe data access component are at risk of causing data corruption. Understanding the transactions lets you know the kind of data they handle, the frequency they’re invoked, and what’s likely to trigger the security-related issue.

Target practice …

Basically, it all comes down to improving our targeting ability to identify the technical debt to focus on. Innovative technologies in the software assessment and measurement area can help target the right issues so that benefits are visible to stakeholders.

Indeed, a SAM solution with program-, module-, and system-level (a.k.a., unit-, technology-, and system-level) analysis and measurement capabilities can help you identify: