From The Due Diligence Show (Episode 6), the Thought Source team talk about how source code is assessed during a technical due diligence project. Source code is sometimes referred to as the “crown jewels” when it comes to M&A transactions, it can certainly be the most valuable part of the intellectual property you are acquiring. When we undertake technical due diligence, it’s a process that we have honed for decades and source code analysis is a craft that, just like technology itself is ever changing. We take you behind the scenes and share some of our “secret sauce”!

Adam Jaques: Welcome back to the deal room, everyone. We’ve got another great episode lined up for you today. Now if you haven’t watched any of the other episodes in the series, I suggest you wind your way back to what we’ve done. We’ve taken you through the path that comes about when you look at buying a technology or a product company, and things about the work that we do, which is technical due diligence from the mindset of people looking at buying companies, and all sorts of things like that. If you haven’t watched it so far, go back. Binge watch the entire series here. But we’re talking today about technical due diligence and what’s actually involved with particularly the software asset. Andrew, you’re our expert here. Sure. Take us through some of it.

Andrew Borzycki: Some of the key things that we’ll look for, are that fundamentally, it’s that the architecture and the code actually matter. A lot. The code because this is the actual product. This is a key part of what you are buying in a technology company. Look how well that structured it is. How the code is licensed that can have a massive impact on the actual value of what you’re buying both immediately and going forward. And whether you can actually meet the goals you’re actually trying to achieve by buying this company. Licensing why is that important? Licensing is one of those things that can massively impact the value of the company. The reason being, almost all companies use open-source software where they have access to the source of something and can incorporate it into their product, but there’s a right way and a wrong way. If you do it the right way there’s a good chance you’ve got a highly valuable asset that can then be purchased. If you do it the wrong way, then you’re getting ready to spend millions and or hundreds of millions of dollars on something you have to give away to the world for free.

Adam Jaques: That’s not blowing things out of proportion. That is actually a potential risk that if open source is not used properly. You can trigger licensing that actually does require companies to release their IP.

Andrew Borzycki: Absolutely. That’s inbuilt to some of the key licensing schemes like the GNU General Public License. One of its goals to ensure that software has is free from the encumbrances of copyright. This is something that is very much goes back to a lot of the philosophy of some of the key open-source contributors in the early earlier history of open source and something that you really need to be careful about during source code analysis.

For those who may not be familiar with what source code is – it is the instructions that a software product is made from. This is what actually tells it when you click on this button or do something it tells it what to do. That is actually the core. That is how you create this product. First up when conducting an analysis, before we even get to the source code, we need to understand its context. This is what the architecture is, the overall design or blueprint of how this software is going to work.

The software plus the architecture that is the product, this is what you are buying. We will gather the engineering team and we’ll talk with them to understand what the architecture is. First of all, is there even one documented? I know I’ve been in some diligences where the discussions we’re having are the first time the architecture has been documented and put on the board. It’s one of the first time that the where all of these things actually come together. In a more mature company, you would expect architecture to be more formalized. If you’re buying an early-stage company, in the rapid growth phase, this often may be the first time this has actually been documented.

Luke Silcock: It’s one of my favorite parts of the review when the engineers are talking to engineers. While other materials such as marketing oriented PowerPoints or company overviews are insightful, it is different to engineer to engineer level discussions.

Andrew Borzycki: Engineering discussions can be different to other areas, such as marketing or sales related information. The standards and what is considered important are often very different to what is considered important in the marketing world. Accuracy, almost blunt truthfulness are key attributes which are valued and that’s where we can learn an awful lot about how a product actually works through engineering discussions. Warts and all, you will learn the details of what it actually does. The way we do that is once we’ve got that architecture understood, we will go through what I like to call a code tour where one of the engineers will go through and walk me through the code. We could cover areas like how we add a new user,  this is how somebody logs in or this is how it does a transaction. They would show me all the different pieces of the code and the architecture to get touched when that happened. So that gives us an idea to actually work out how much of this is real or not.

Adam Jaques: Talking about talking about source code access. How do you get given access to the source code?

Andrew Borzycki: That varies quite a lot according to the company. I’ve had to deal with lots of different variations over these because understandably, this is the company’s core asset. I’ve had every variation of “here you go, here’s the code on a USB stick, just make sure you don’t do anything bad with it,” to, “here’s a computer in our office which is not connected to the internet”. Chaperoned access is another variation. This is an arm’s length tour with somebody. An engineer from the company will be stepping me through different things where they are driving the computer. Other times I’ve had remote access to a computer on the other side of the world where I just get a chance to look at the code over a few hours while are working with the rest of the team.

Luke Silcock: That’s the divide and conquer strategy. What Andrew is referring to there is you can have a management track. And we’ll be exploring lots of really interesting topics. At the same time that frees up the lead engineers to talk in a more natural way without the executive restrictions.

Andrew Borzycki: There is a difference of focus and emphasis as we get to this level of code and detail. It often means that we will get access to the engineers unsupervised, so to speak, where they are actually, without the executive oversight, executive interpreting, executive explaining, etc.

Adam Jaques: This leads onto the idea of “stage management.”  There can be this gap between the product vision and what it does today. We are trying to distil “what does the product do today? What is the quality of the product? We will explore these differences in another episode.

Andrew Borzycki: Speaking about in the product side, that is, believe it or not, one of the most difficult things. To actually ascertain what where a product is today. Where it is versus where it will be because the technology companies are moving so quickly and the product doesn’t do that yet. But it will do that in a few months. Getting clarity about that is surprisingly difficult in a lot of situations because the team you’re working with are focused on the future, and what’s going to be in the product, not where it is. It’s really difficult to get that and so through discussions with the engineers, the right level of detail is uncovered.

Adam Jaques: Questioning along “this is what it does, and take a slice of code that does this”. Then ascertaining that what was shown is currently released.

Andrew Borzycki: Yeah, exactly. At that point in time when we’re doing the review, we look at it for a variety of things like its complexity level, how modular it is. This means how well broken up it is. Can I change something over here without then breaking this thing over there. All of that then leads to an idea about how maintainable or not this product is. A key by-product of doing all of this is that I’m getting a chance to talk to the team in a really deep level of understanding about what they know, their capabilities and their passion.

The quality of the team is one of those other areas that makes all the difference to the value of the company going forward. You may have the key team who are you know, the people who are the founders, they’ve been there for years, they understand what’s going on. Or you may have folks who are the caretakers they don’t really know the guts of it. They know the outer shell of what’s going on, who may have difficulty in growing the product. All of this may impact you as an acquirer if you then want to go and evolve and grow this thing.

Luke Silcock: One of the other things we often look for is hidden away in the source code control. If, for example, there are 300 people working on a piece of software, source control lets them do that in a way so they don’t step on each other’s toes. Each person does their bit. We have a nice history and they don’t disturb each other. A good by-product of that is you work out who’s what who’s worked on the product for the entire history of the company. It’s the Revision History of the asset base.  You will be able to help us get informed and we can share with the HR workstream who are the key contributors. We can learn what areas of the code they are contributing to. And from firsthand knowledge, what are they like? We can also see productivity rates and how that has fluctuated over time.

Andrew Borzycki: Yeah, exactly. All of this gives you an indication as to how suitably equipped this team is to take this thing going forward for you.

Adam Jaques: And what about search criteria like you look at you do certain searches rather than the source code? What sort of things do you look for?

Andrew Borzycki: one thing of course, is a profanity filter? Which, just checks the language in the code.

Adam Jaques: Alright, lesson learned, yeah, be careful of swear words through the code.

Andrew Borzycki: Other examples of things like to do is look for “todo” statements. Writing software is an incredibly difficult mentally taxing activity done in a context of where you’re constantly trying to balance, how long it’s going to take, what I’m going to do and the quality level you want. You need to balance all of these things together. I may skip doing this particular piece here, because it’s not something that’s immediately urgent compared to what I’m actually working through. Of course, the trouble is that as time goes, on these may accumulate and the importance of each of those todos is something which often need more digging into. This is to determine if something is actually really important or it only affects this person once every five years on a Thursday or something weird like that.

Luke Silcock: We love these. An edge case is that a bit of code that handles an exception error or unusual situation that happens rarely.  I can be something that relates to scalability, where a theme was kicked down the road. That becomes an accumulated tech debt that needs to be addressed, particularly if the acquirer is looking at growing massively the usage of the platform. And that’s one of the key objectives of diligence. To make sure you don’t have an accumulated pile of backlog that’s dealing with scalability and performance under load.

Adam Jaques: Guys, great content as always, and really interested to hear your insights Andrew as to how you’re digging under the covers there. I think always sensing there’s probably enough content in all this for more episodes in the future. Next episode, what I think we should focus on is more about the product due diligence. What is the actual product and how it fits into the market. We’re looking forward to seeing you really soon.



The Thought Source team have produced a video series covering the "behind the scenes" of performing technical due diligence for M&A projects.

Contact us now, to discuss your project requirements