Code quality metrics are a fundamental component of technical due diligence, but not all metrics are equally informative. During M&A assessments, the goal is not to achieve a perfect score on every possible metric but to identify the measurements that reveal the most about the maintainability, reliability, and scalability of the target's software assets. This guide focuses on the metrics that consistently provide actionable insight during due diligence engagements.
Test Coverage and Test Quality
Test coverage is one of the most commonly cited code quality metrics, but raw coverage percentages can be misleading. A codebase with 90 percent line coverage but only trivial assertions provides a false sense of security. During due diligence, evaluate not just coverage levels but also the quality and meaningfulness of tests. Examine whether tests validate business logic, handle edge cases, and test integration points between components.
Assess the distribution of test types across the testing pyramid. A healthy codebase should have a large base of fast unit tests, a smaller set of integration tests, and a focused suite of end-to-end tests. Inverted testing pyramids, where the majority of tests are slow end-to-end tests, indicate a codebase that is expensive to test and maintain.
Evaluate the test execution time and reliability. Flaky tests that intermittently fail erode developer confidence in the test suite and slow down the development process. If the development team routinely ignores test failures or reruns pipelines until tests pass, the test suite has lost its value as a quality gate.
Complexity and Maintainability Metrics
Cyclomatic complexity measures the number of independent paths through a function or method and correlates strongly with defect density and maintenance difficulty. Functions with high cyclomatic complexity are harder to understand, test, and modify. During due diligence, identify the distribution of complexity across the codebase and flag hotspots where complexity exceeds acceptable thresholds.
Cognitive complexity, a newer metric, attempts to measure how difficult code is for a human to understand. Unlike cyclomatic complexity, it penalizes deeply nested control structures and rewards well-structured code that follows linear logic. This metric often provides a more accurate assessment of real-world maintainability than cyclomatic complexity alone.
Dependency and Coupling Metrics
Afferent and efferent coupling metrics reveal how interconnected components are within the codebase. High efferent coupling means a component depends on many other components, making it fragile and sensitive to changes elsewhere. High afferent coupling means many components depend on a given module, making changes to that module risky and potentially far-reaching.
Evaluate the dependency graph for circular dependencies, which indicate architectural problems that make the system difficult to build, test, and deploy incrementally. Assess the use of dependency injection and interface abstractions that promote loose coupling and testability.
Third-party dependency health is equally important. Evaluate the number of direct and transitive dependencies, their maintenance status, known vulnerability counts, and license compatibility. A codebase with hundreds of unmaintained or vulnerable dependencies presents both security risks and migration costs that must be factored into the acquisition assessment.
Change Hotspot Analysis
Change hotspot analysis examines version control history to identify files and modules that are frequently modified. Files that change often are either central to the system's functionality or symptomatic of poor design that requires constant adjustment. When high change frequency correlates with high complexity, it identifies areas of the codebase that are both risky and expensive to maintain.
Combine change frequency data with bug fix commit analysis to identify areas where defects cluster. Modules that consistently generate bug fix commits despite frequent changes suggest fundamental design issues that incremental improvements will not resolve. These findings often point to areas that will require significant refactoring or rewriting post-acquisition.