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.
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 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?
Among the many challenges are:
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.
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:
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.
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:
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.
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:
This is along with the security-, reliability-, efficiency-, and changeability-related issues they embed.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.