Investment activity is down now, but it’s likely to pick up in 2023. And when investments ramp up, so does M&A. Will your organization and your code pass technical due diligence when it’s your turn?
Let’s start with the positives: If an investor is proceeding with technical due diligence (TDD), you’ll likely pass. You’ve passed the tests for product-market fit, financials and competitive differentiation well enough that they now want to look under the hood.
Here’s the not-so-good news: Companies can pass the business test, but fail TDD. Especially for non-technical executives, the code-examination process can feel like … an audit … conducted in another language … with a loud clock ticking away incessantly. Not fun.
Our firm has analyzed the code of hundreds of billions of dollars worth of deals, from three-person software companies to firms with thousands of developers. We’ve looked at the contributions of over 200,000 developers who have collectively written 4 billion lines of code.
Poor codebase health is more often than not “caused” by other teams rather than by engineering.
From that dataset, we’ve distilled eight questions that you can ask yourself now. Even if TDD is not on the horizon, having good answers to these questions will ensure your codebase is healthy.
A quick primer on TDD
Before we go any further, here’s a bit more context on technical due diligence for software:
- TDD applies to traditional software companies and non-software companies enabled by custom created software.
- It involves the examination of code written by employees or contractors.
- TDD is conducted by in-house experts or by specialist consultancies.
- Investors and acquirers, especially the larger and elite ones, may ask to conduct a quantitative code scan to supplement qualitative interviews. Such a code scan is effectively mandatory if the investor is seeking reps and warranties insurance (RWI) for the deal.
The goals of TDD are to:
- De-risk the deal by determining if the codebase is safe enough for investment.
- Identify opportunities for improvement if the transaction goes through.
We say “codebase” because it’s more than just the source code that’s under the magnifying glass. Your documentation, processes and most importantly, the software developers will also be under examination. The functional scope of TDD includes code quality, code security, intellectual property, DevOps, IT and, sometimes, product management.
Because it’s more than just the quality of the code, we talk about codebase health to encompass all of these areas.
Question 1: What have you been working on?
Making sure that the organization is working on the software products that matter most is an important part of de-risking the deal.
This may sound obvious, but sometimes, a company claims to be working on a new product, but will actually be spending the majority of their time on custom development for major clients or not working much on anything at all.
Consider this example of a company’s software development over two years. Not only is there a cyclicality in the work (higher in summer), but it has declined significantly over time, especially in 2022.
Image Credits: Sema
Important point: Here, and for all questions in TDD, any answer might be sufficient to clear the examination.
This leads us to TDD Theme #1: The most important part of TDD is ensuring the state of the codebase is aligned with the organization’s business objectives. For example, U.S. education software companies typically see cyclical software development — higher in summer and lower in fall — to minimize disruption for customers when school starts.
Question 2: How much unit testing does your codebase have?
We like to distinguish between underlying code quality to include such measures as its maintainability or the ability to be extended, and the functional code quality — how the product works for users.
“Technical debt” is another way of describing any lack of perfection in the underlying code.
No codebases have perfect underlying code quality, so you could say that all codebases have technical debt. If they did not have tech debt, nothing would ever get shipped and dev teams would only be working on fixing the code.
This leads to TDD Theme #2: Codebase health is contextual and there is no “one-size-fits-all” level necessary to clear TDD.
The question is whether the amount of technical debt is suitable for the stage, size and sector of your codebase and company. A Series A company with five developers working on identifying plants from a photograph (shout-out if that’s your firm!) would be expected to have substantially more technical debt, adjusted for size, than a large, late-stage fintech company.
One particularly common type of technical debt is a lack of testing, especially unit tests. Unit tests make it easier for developers to code quickly, and so their absence negatively impacts team velocity.
But it also may be too soon to invest in eliminating technical debt. If you’re still working on product-market fit or refining new features, adding unit tests is a waste of time and shows a potential risk of over-engineering.
In diligence, you’ll be asked to explain how you arrived at the testing levels in the codebase, and how they vary by application (hopefully! See Question #6).
Question 3: Does your security program match your company’s maturity?
Our data is unequivocal: Almost every software product has security vulnerabilities.
This may sound surprising to non-technologists, but software engineers know that it is practically impossible to prevent all security issues from making it to production while still shipping code. Investors and acquirers know this. So while they are most certainly interested in the number and severity of potential security issues and will prioritize clean-up after the transaction, they will put that security risk in context.
A higher level of security risk is typically acceptable for new companies, new products and products dealing with low-risk/less-regulated industries. So you’ll be asked to explain how your approach to security risk matches your stage, size and sector, just like with other kinds of tech debt.
Here’s an example of a company with 239 current security warnings, charted by when those security warnings were introduced into the code. Only 12 of the 239 warnings, or 5%, were introduced in the last six months. That means that 95% of the security warnings have been in the code for six months or more, and 45% have been in the code for more than two years.
Image Credits: Sema
This data is clear that finding and remediating existing security warnings is not a priority. Whether that is acceptable to pass TDD or not depends on the business context.
Question 4: Are your subject matter experts in the building?
It is a common misconception that investors and acquirers only care about the code. And that leads us to Theme #3: The single most important factor for a codebase to clear TDD is if the developers who have created or maintained the code are still active at the company.
Developers know why. No matter how good your documentation is, code is simply too contextual, nuanced and situational to be perfectly codified. If the engineers actively involved with the code are no longer around, it can take months or longer to train new hires. This delay can make a difference to product roadmap goals, and therefore, TDD success.
The closest non-tech example might be writing a novel. Even if you had all of the drafts, replacing an author would dramatically slow down the writing and dramatically lower the quality and coherence.
Here’s an example from TDD (names have been changed and data has been styled). This chart shows developers based on how much work they have done, how long they’ve been at the company and how long it’s been since they last coded.
Image Credits: Sema
Grace, for example, is the fifth-largest contributor to the code, she’s been at the company for 328 days, and she coded the same day when the code scan was conducted (zero days since last coding).
This chart clearly shows that the top four largest contributors to the code likely are no longer with the organization. This is a risk to the deal. The code owner should be ready to explain why the developers left (assuming they didn’t move into management, product or some other department) and how well the company handled knowledge transfer before they left.
Question 5: Do you know what third-party code you are using?
This is a trick question, because no one knows about every third-party code. The real question is: Do you know about and have you managed the risk for most of your third-party code?
Let’s back up. When an engineering team is creating a new product, they are faced with the “build or buy” decision. “Building” we know, that’s the team creating the code from scratch. “Buying” refers to using code written by another person or organization — third parties.
The most common ways to use third-party code are through a commercial license or referencing open source code. Open source code is a spectacular way to advance the product roadmap rapidly while maintaining quality, so it’s quite prevalent — 96% of commercial code relies in part on open source code.
The challenge is that third-party code comes with significant risks. The external code can become out of date, contain security vulnerabilities or have a commercially dangerous license. We won’t bore you with an intellectual property law lesson, but some open source code can come with stringent provisions that you must give away your code for free. This is called a “CopyLeft” license.
Any developer can go on GitHub or GitLab and pull down open source code and they can do so without adding it to the “table of contents” of third-party code. So, in practice, it’s safe to assume that 100% of tech companies use some unknown open source code.
Thankfully, most open source or third-party risk is correctable after a deal closes, so unknown or risky licenses are usually not deal breakers. However, it’s always the right time for engineering to get a handle on what they are using.
Question 6: Can you explain the observed variation across codebases?
So far, we’ve been thinking about the codebase in a monolithic way — all of the code of an organization as one entity. The number of security warnings or the amount of testing that has been done are all considerations that can be addressed by looking at all of the code together.
In practice, though, almost every company’s code exists not as one entity, but in the form of subgroups. Code is stored in repositories, and one or more repositories make up an application. Those applications themselves are likely at different stages of their lifecycles and are of different levels of importance to the business.
Potential investors will want to understand that you are taking these factors into account as you build and maintain the codebases. Are you deliberate and intentional with your engineering resource allocation? Code quality investments should not be spread like peanut butter.
A common misconception sellers have is that their company will look bad if their older codebases “look worse” (i.e., have more tech debt) than their newer ones. The opposite is true: Codebases at identical quality levels that are at radically different stages of the lifecycle is a red flag to investors.
That’s because as much as the world runs on code and depends on coders, developers tend to improve code quality beyond the levels necessary for the business. (This is an understandable and welcome trait — coding is a craft, after all.) Good organizations are able to make thoughtful trade-offs between the pace of feature delivery and underlying code quality.
One example of unusual variation from our data: Here is the average level of technical debt (higher is worse) across five applications owned by the same company. Can you guess which one drew the most attention from prospective investors?
Image Credits: Sema
Question 7: How much does finance invest in tech debt prevention and remediation?
Reading these questions, you could assume that TDD is only about the technology team. Some CEOs and CFOs leave the conversations to the engineering leadership and, worse, blame them when things don’t go well.
The reality, as savvy investors know, is also TDD Theme #4: Codebase health is driven by the entire organization, not just engineering.
Sales, finance, product, CEO and the head of engineering can each contribute to deciding, for example, if engineering is permitted to invest a percentage of the roadmap each year in finding and remediating security warnings, or what happens when sales has last-minute requests for the roadmap that would deprioritize codebase investments.
We’ll go a step further: Poor codebase health is more often than not “caused” by other teams rather than by engineering. In our experience, developers almost always want to make the code better.
So if you’re the technical leader responsible for answering questions in a diligence session, as stressful as it is, take a breath and remember it’s not a reflection just on you; it’s a conversation about the whole organization.
Question 8: Are you ready to learn and grow?
We’ll be the first to say that TDD is rarely a delightful experience. Incredible hard work and sacrifice goes into getting to an exit or the next funding round and it’s beyond nerve-wracking to have your work evaluated by an outsider with such high stakes.
What makes this even harder, on top of all of the technical questions, is that TDD is simultaneously an evaluation of the leadership team. They’ll be evaluating how you respond, how data-driven your answers are and how thoughtfully you assess risks and remediation.
Our best advice is to imagine that you are “on the same side of the table” as the interviewers. You are engaged together in an exercise to figure out the current state of the codebase, its strengths and areas of improvement.
Of course, we know that until the deal closes, there are indeed two sides of the negotiation. But if you’ve made it to TDD, the other conditions for the deal have likely been met. Demonstrating that you are a thoughtful problem-solver, are clear-eyed about the state of the codebase and open to feedback will give investors and acquirers greater confidence that you’ll be able to lead the inevitable improvements. And that only increases the likelihood of the deal going through.
In conclusion
If your diligence is right around the corner, then thinking about these questions just for an evening will leave you in a better position to respond when you eventually face them. And to make it a little easier, here’s a checklist you can complete with more of the questions you might face.
To recap:
- Theme #1: The most important part of TDD is ensuring the state of the codebase is aligned with the organization’s business objectives.
- Theme, #2: Codebase health is contextual and there is no “one-size-fits-all” level necessary to clear TDD.
- Theme #3: The single most important factor for a codebase to clear TDD is if the developers who have created or maintained the code are still active at the company.
- Theme #4: Codebase health is driven by the entire organization, not just engineering.
Even if there isn’t a tech due diligence process on the horizon, these are still good questions for the leadership team to regularly consider and use to adjust organizational practices. That’s because the fundamental themes of codebase health that great investors care about are also operational and strategic decisions that will help create code to support a great business.