Table of contents
Intro
M&A and investment activity is coming back in 2023. Will your organization, and your code, pass technical due diligence when it’s your turn?
Let’s start with some good news. If an investor is proceeding with technical due diligence (TDD), you’ll likely pass. You’ve made it through the tests of product-market fit, financials, and competitive differentiation that they want to look under the hood.
Now the not so good news. Companies can pass the business test but fail TDD. And for non-technical executives, the process of examining your code can feel like … an audit … with a loudly clicking clock .. conducted in another language. Not fun.
Our firm has analyzed the code of hundreds of billions of dollars worth of deals, from three-person software companies to mega firms with thousands of developers. We’ve looked at the contributions of over 200,000 developers who’ve collectively written four billion lines of code.
From that dataset, we’ve distilled eight questions that you can ask yourself now, whether TDD might be coming in a week, a month, a year or beyond. And 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, let’s provide a bit more context on Technical Due Diligence (TDD).
- TDD applies to traditional software companies and non-software companies enabled by custom created software
- It includes code written by employees or contractors.
- TDD is conducted by in-house experts or by specialist consultancies.
- Investors and acquirers, especially larger and elite ones, may ask to conduct a quantitative code scan to supplement the qualitative interviews. Such a code scan is effectively mandatory if the investor is seeking Reps & Warranties Insurance (RWI) for the deal.
The goals of TDD are to
(1) de-risk the deal, determining if the codebase is safe enough for investment, and
(2) identify improvement opportunities if the transaction occurs.
We say “codebase” because it’s more than just the source code– also documentation, processes, and most important the software developers. TDD functional scope includes code quality, code security, intellectual property, DevOps, IT, and sometimes Product Management. Because it’s more than just code quality, 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 element of de-risking the deal.
This may sound obvious but sometimes a company claims to be working on their new product but is actually spending the majority of their time on custom development for major clients, or not working much on anything.
Consider this example, which shows a company’s software development over two years. Not only is there a cyclicality to the work (higher in summer), but there is a significant decline over time, especially in 2022.
%252C%2520by%2520month.png)
Important point: here – and for all questions in TDD – any answer might be sufficient to pass TDD. This leads us to TDD Theme #1: what matters most in TDD is if 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 underlying code quality, to include such measures as the codebase’s maintainability, or ability to be extended, as distinct from 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. In other words, all codebases have technical debt. If they did not have tech debt, nothing would ever get shipped, dev teams would only be working on fixing the code.
This leads to another TDD Theme, #2: codebase health is contextual, there is no “one size fits all” level necessary to pass TDD.
The question in TDD 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, in particular unit tests. Unit tests make it easier for developers to code quickly – and so their absence negatively impacts team velocity.
But it also can 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– ways that the code has written that makes it more vulnerable to potential information leakage or attack.
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 cleanup post-transaction, they put that security risk in context.
A higher level of security risk is typically acceptable for (a) newer companies, (b) newer products, and (c) products dealing with lower risk / less regulated industries.
And, so, in TDD you’ll be asked to explain how the approach to security risk matches your stage, size and sector, just like with other kinds of tech debt.
Here’s an example: 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 6 months or more. 45% have been in the code for more than 24 months/ 2 years.
.png)
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 / acquirers only care about the code.
In fact, having software developers who’ve created or maintained the code still be active at the company is the single most important factor in whether a codebase passes TDD. This is Theme #3.
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 who are actively involved in the code are no longer there, it can take months or longer to train up new colleagues. This delay can make the difference to the 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 lessen the quality and coherence.
Now 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.
Grace, for example, is the 5th largest contributor to the code, she’s been at the company for 328 days, and she coded the same day as when the code scan was conducted (0 days since last coding).
This chart shows clearly that the top four largest contributors to the code likely are no longer with the organization. This is a deal risk. 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 robustly the company did knowledge transfer before they left.
Question 5: do you know what third party code you are using?
Gotcha – this is a trick question: 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, that is, third parties.
The most common ways to use third party code are through a commercial license or referencing Open Source code, based on the contributions of millions of developers across the world, predominantly as volunteers.
Open Source code is a spectacular way to advance the product roadmap rapidly and with quality. No reason to rebuild a clock function if you have a standard use case. And so it’s widely prevalent – 96% of commercial code relies in part on Open Source code.
The challenge is that third party code comes with significant risks – that 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 (aw, shucks!), 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 individual 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, by adding it to a package manager.
And so, in practice, 100% of companies have some unknown Open Source code.
Thankfully, most Open Source / Third Party risk is correctable after the deal is closed, so it’s usually not a deal breaker to have unknown and or risky licenses. But it’s always the right time for Engineering to start to get a handle on what they are using.
Question 6: Can you explain the observed variation across codebases?
Up to now, we’ve been thinking about the codebase in a monolithic way [sorry / not sorry for that tech pun]: across all of the code of an organization as one entity. How many security warnings, how much testing, etc. are all questions that can be answered by looking at all of the code together.
In practice, though, almost every company’s code is not one entity, but split into subgroups. Code is stored in repositories, and one or more repositories makes up an application. Those applications themselves are likely at different stages of their lifecycle, and different levels of criticality to the business.
Potential investors will want to understand that you are taking these factors into account while you build and maintain the codebases: are you deliberate and intentional in 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.
Why is this? as much as the world runs on code and depends on coders, there can be a tendency for developers to improve code quality beyond the level necessary for the business need. [This is an understandable and welcome trait– code is a craft, after all]. Good and great organizations creating code are able to make thoughtful tradeoffs between speed 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 the prospective investor?
Question 7: What investment does Finance make in tech debt prevention and remediation?
Up to now, 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: lower codebase health is more often than not “caused” by other teams rather than by Engineering. In our experience Devs 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.
Making it even harder,on top of all of the technical questions, TDD is simultaneously an evaluation of the leadership team. They’ll be looking for how you respond, how data-driven your answers are, how thoughtful are your assessments of 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 a shared exercise to figure out the current state of the codebase, its strengths and its areas of improvement.
Of course– we know that until the deal closes, there are indeed two sides of the negotiation.
But if you have made it to TDD, the other conditions for the deal are likely met. Demonstrating that you are a thoughtful problem solver, that you are clear-eyed about the state of the codebase and open to feedback, gives investors & acquirers greater confidence that you’ll be able to lead the inevitable improvements– which increases the likelihood of the deal.
Conclusion
We’ve covered eight questions that you could get asked during TDD that you can ask yourself at any time.
If your diligence is right around the corner, then even thinking about these for an evening will give you a leg up rather than hearing them for the first time on a Zoom call.
And to make it a little easier – here’s a checklist you can complete with more of the questions you might face.
And even if there isn’t a tech due diligence on the horizon, these eight questions are still good questions for the entire leadership team to regularly consider and use to adjust organizational practices.
- Theme #1: what matters most in TDD is if the state of the codebase is aligned with the organization’s business objectives.
- Theme, #2: codebase health is contextual, there is no “one size fits all” level necessary to pass TDD.
- Theme #3: having software developers who’ve created or maintained the code still be active at the company is the single most important factor in whether a codebase passes TDD.
- Theme #4: codebase health is driven by the entire organization, not just Engineering.
That’s because the fundamental themes of codebase health that great investors care about in making their decision are also operational and strategic decisions that matter for creating code to support a great business.
