Posted by on Wednesday, January 13th, 2021

Design quality audits are sometimes overlooked in software due diligence, but they are vital to understanding the overall health of a company’s software system.

When software is part of an M&A transaction, performing technical due diligence is a critical part of the process. There’s a lot to cover when it comes to software due diligence, and you can learn more by reading our take on the specific areas of the process, but today we’d like to discuss software quality.

One aspect of software quality that is sometimes overlooked is design. The Synopsys Audit Services team performs hundreds of audits every year, often for M&A scenarios, and software due diligence typically includes a manual review of the architecture of the target company’s software. And while this review is a very important aspect of software due diligence, it won’t provide a complete picture of how the code is structured and the implications that may have on future development. Complementing manual review with analysis of the structure of the actual code enables buyers to understand the health of the codebase and what will be required to improve it going forward.

A manual review of the architecture is often performed for the acquirer by the target company’s technical leadership. This review typically illustrates the functionality and design elements with flowcharts and high-level architecture diagrams. But it doesn’t generally go into details of the actual software implementation, so it can’t easily identify problem areas of the codebase.

Synopsys auditors have examined the software systems and development practices of hundreds of companies and have observed certain trends emerging over the years. We found that the high-level design elements don’t always tell the whole story. How this high-level architecture is translated by the developers into working pieces of code, and how the codebase evolves over time, can make or break the stability and performance of a system.

The importance of design quality

A well-designed (or architected) system allows developers to understand the different parts and have a clear sense of the relationships between those parts. Interview-based audit methods help us document this architecture so buyers can better understand the layout of the system, the layout of the team, and the ways developers think about their code and manage their organizations.

Here is an example of a good design:
Architect’s view vs. developer’s view

Unfortunately, we find that in 80% of complex codebases, there’s a discrepancy (sometimes a significant one) between how developers in the target company think about their code and what is actually in their codebase.

Factors to assess during software due diligence

Over time, as the implementation details stray from the intended architecture, the system diagrams shared by the target reflect the current system less and less. Developers are often on tight deadlines to ship and are forced to skip best practices like code reviews, automated testing, or secure programming practices. Lack of testing and related best practices lead to codebases that are patched together in a hasty fashion, and they can become messy and brittle. Testing messy code that is highly interdependent can be challenging and time-consuming. A codebase that breaks with a small change is difficult to maintain. All these factors should be assessed as part of software due diligence, so the acquiring company can understand things like:

• How many resources do they need to allocate for fixing potential design issues?
• How much tech debt do they need to plan for?
• How much time are developers spending fixing brittle code vs. shipping new functionality?
• How much time and cost will be associated with making code changes in the future?
• Will they need to refactor parts of the codebase?

Benefits of a design quality audit in software due diligence

A Black Duck® Design Quality Audit serves as a bridge between the high-level architecture and the actual implementation to provide a complete picture of the quality of the target company’s software systems. This type of audit is also useful in measuring the modularity of a system and identifying problematic components. It provides insight at the source code level and assesses maintainability of the system as well as the underlying components.

By using the fully automated CodeMRI scanning tool by Silverthread, we can discover areas where modularity in a codebase has broken down in ways the developers don’t even understand. For example, we identify highly interdependent pieces of code that can be difficult to maintain and enhance. The more cyclical dependencies a codebase contains, the higher the chances of defects being introduced as developers work on it. This is important because studies have shown that these architectural “hotspots” (known as cores in academic literature) are also places with significant defects and where developer productivity grinds to a halt. Rapid and automated design quality analysis can identify these risky hotspots, like the ones called out in the unhealthy architecture below, so a plan can be put in place to fix them and move toward a healthier, modular, layered, and hierarchical architecture like the image on the right.

Higher defect rates and diminished developer productivity lead to longer development times, which lead to increased costs and delayed releases. A Design Quality Audit can both zero in on areas of concern and provide estimates for maintenance costs and expected defect rates as new features are added to the system.

In addition to identifying trouble spots, the audit also assists with the difficult decision of whether to refactor an existing codebase or rewrite components to improve overall quality. Expert review of audit data can also help uncover underlying organizational issues such as lack of focus on testing or a shortage of experienced technical resources. Acquirers that are faced with evaluating a target company’s software systems must adopt a multipronged approach to this analysis to ensure they have all the information they need to plan for a potential integration.