Quantifying software quality risks in tech M&A

by Phil Odence on September 25, 2019

Tech M&A typically evaluates security and legal risks, but what about software quality risks? Poor code and architecture quality can have a lasting impact.

Tech deals are those in which software assets are a significant part of the valuation of the target company. When a bank buys a bank these days, software is important, but when a tech company or private equity buyer acquires a software-based product company, the technology is the deal. In that scenario, among all the other due diligence considerations, identifying risks in the software rises in importance to the top of the stack.

All software technology has issues, but it’s critical for buyers to have as clear a picture as possible before the deal is closed so they can address issues or plan how to post-close. Risks in software include legal risks, primarily around improper licensing; security risks, vulnerabilities in the code or design that could be exploited; and software quality risks. Security and legal risks can get you in trouble—think lawsuits or breaches. The consequences of quality risks are, at the same time, less acute and more insidious. Poor quality adds friction, bogging down future development and maintenance, and can also inhibit scalability. A lousy “gift” that keeps on giving … giving headaches to unwary acquirers.

How to evaluate software quality risks

So, along with auditing for open source and third-party software and ferreting out security vulnerabilities, comprehensive software due diligence should look at software quality from three angles: processes, architecture, and code. Through techie-to-techie discussions, buyers can gain an understanding of the maturity of the development process and a qualitative sense of the architecture and code. They might infer that a smart architect and a good diagram probably means well-structured code and that a good development process probably means a manageable level of bugs. However, buyers generally can’t get their hands on the codebase, which is really required to validate that the architecture and code are, in fact, in good shape and to quantify the issues if they are not.

Sponsorships Available

As a highly-trusted third party, we do get the code, typically to evaluate its open source content. For several years, we’ve also offered the option of static analysis to quantify the bugginess via our Code Quality Audit. Recently we added a Design Quality Audit (DQA), powered by a unique tool called CodeMRI from Silverthread. CodeMRI enables our software architects to evaluate not just the bugginess of the code but also the quality of the architecture, which is often not so well-structured and hierarchical as the pretty PowerPoint rendering would suggest.

How a Design Quality Audit works

Both dimensions of quality are critical to examine. Buggy code brings with it a backlog of work to fix and also reflects poorly on the developers and process behind its construction. Poor architecture, on the other hand, means that every time developers touch the code, whether to fix a bug or add a feature, they will be substantially less productive. In this scenario, because even small code changes touch functions all over the codebase, developers end up spending more time fixing stuff they inadvertently break than actually making changes.

Powered by Silverthread, the DQA provides deep insights into a software system’s design or architectural health and the likely cost of ownership and the resulting risk-related consequences. The DQA captures architectural health metrics from a codebase, creates visualizations, benchmarks against thousands of comparable systems, and identifies design degradation. Finally, it uses predictive analytics to model the economic impact of design health.

A DQA report enables buyers to evaluate the drag that the architecture is putting on code development and plan how much refactoring needs to be part of the integration process. In the extreme, when the actual architecture looks nothing like the pretty picture, an acquirer might want to reconsider the valuation or efficacy of the deal altogether. That ain’t a pretty picture, but it’s far better to identify such an issue pre-close, when the buyer can still do something about it.

To learn more about why software quality matters in tech M&A, check out our upcoming webinar, Do Design Quality and Code Quality Matter in M&A Tech Due Diligence?

Or download the Software Quality Audits datasheet to learn more.