Software Due Diligence – Focus on Contributors and Their Cooperation

Summary

• The success of a software company takeover depends to a large extent on the retention of key developers.
• The DETANGLE® Software Analysis Suite identifies different groups of key developers.
• The acquisition risk decreases if the investor can conceive measures at an early stage to retain these employees.
• The tool also analyses the entire effort and knowledge distribution in the development team. The optimisation of knowledge distribution enables quality and efficiency improvements. 
• An optimised knowledge distribution also reduces the dependency on individual persons.

Introduction

Software is a product that must be able to adapt quickly to rapidly changing market/user requirements with little effort. It is therefore clear that both, qualified developers and highly effective working methods, represent a considerable part of the company’s value. However, developers are also “walking assets”. They can decide at any time to be unavailable to the project at short notice. Such dependencies or, in this context, know-how deficiencies in individual teams should be identified and assessed as significant risks for an investor prior to the investment decision.

We have already addressed the topic of software quality in a due diligence in the last article: Avoid pitfalls in a software due diligence.

Why is it important to analyse developers and development methods?

Identifying key contributors and also the code areas that have been worked on exclusively by one developer are prerequisites for being able to assess the risk to successfully developing the software further.

Questions like the following should be asked and can also be answered with the necessary depth within the tight time frame of a due diligence: 

1. Who are the key developers and why?
2. Does the skill/knowledge distribution between the project contributors correspond to the requirements of the project/product? 
3. Is the development load evenly distributed?

An automated analysis of knowledge and cooperation patterns by DETANGLE® provides data-based answers to such questions.

Does losing a top developer potentially bring down a project?

At first glance, it only seems advantageous to have a few star developers in the team. Retrospectively, that may be true, but an investor buys and pays for the future. Software development is teamwork. If these stars represent islands of knowledge and develop and maintain important parts of the code alone, then these employees also represent a risk, because the further development of the software depends on them staying in the project.

more than 70% of projects suffer from a bus factor of 1.
— THE BUS FACTOR – WHY YOUR ‘BEST’ DEVELOPER IS YOUR BIGGEST PROBLEM [1]

This means that only one key developer has to leave the project to seriously jeopardise the further development of the software!

How can we identify the relevant contributors?

So who are the real key developers and how can they be objectively identified? Gut feeling is a poor guide. For example, quiet team members can be overlooked who are doing a top job without a fuss, in addition to sharing their knowledge and also making very few mistakes.

Basically, there are two basic types of relevant developers. 

1. Soloists: These are developers who are islands of knowledge and prefer to work alone. They often show a high work output. However, these knowledge islands must not get out of hand and should not remain as such for too long.
2. Team stars: They share their knowledge with other developers in addition to their “individual work”. These are also very productive, but bring the overall team performance forward and reduce the risk of becoming dependent on individual soloists.

With DETANGLE® it is easy to identify both groups of key developers and their bus factor. We at Cape of Good Code have developed metrics and KPIs for this, which DETANGLE® derives directly from the history of the code in the code repository, and thus provide objective and comprehensible results. These analyses are only supplemented with a few short interviews to round off the picture. The risk of dependencies becomes thus transparent. This gives you the chance to work out concepts in time to keep these top performers in the company after the change of ownership. If this seems impossible, you need to check whether the risk does not represent a red flag for the transaction.

How to measure the distribution of knowledge in the team?

Another important aspect of the risk assessment is the distribution of knowledge and workload in current projects. To gain more insight, it is part of our software due diligence investigation to measure and visualise whether these knowledge islands are compensated by knowledge exchange and thus dissolved in the medium term.

Figure 1: Distribution of knowledge and development effort

The figure shows as an example a visualisation of the measurement results from an open source project after a DETANGLE® analysis. It is clearly visible that there is a significant section of the code where only one key developer was involved (“knowledge island”). If this employee drops out, and if his work is also poorly documented, it is hard to continue the development with normal effort. There is also an area (“knowledge tangle”) where many team members create code, but no one is obviously in charge (see also our blog on “Cooperation and Knowledge Sharing for Remote Agile Development” at [2]). According to our measurements we expect many bugs in this part of the code. Finally, however, a good example (“knowledge sharing”) can be seen where one developer dominates but shares a significant part of the work with two other developers. 

Take Aways

A software company is a knowledge organisation. Especially in smaller software companies, employees are therefore the most valuable but also the riskiest assets. We strongly recommend that this risk be professionally analysed in the due diligence process.

Cape of Good Code has developed an analytical, software-based approach to identify key employees, skill and know-how risks in a differentiated and comprehensive manner. This allows an investor to plan leadership and action priorities from Day 1 (acquisition day) in a timely manner and implement them immediately.

Frequently Asked Questions (FAQs)

1. How can you be sure that there is no uncontrolled data and IP leakage when examining the code?
   The DETANGLE® analysis software is installed, configured and executed on a machine of the company infrastructure. All analysis results remain on one computer. Remote access to this computer can be encrypted and secured via a VPN connection.
2. How much effort does a Software Due Diligence imply?
   We distinguish between Red Flag Due Diligence, which takes a few days (3-7 days depending on the system size, complexity and scope of the report) and a Deep Dive Analysis, which takes at least 10 days.
   Red Flag Due Diligence focuses on a few predefined topics and examines these topics for critical risks (red flags). It is usually carried out when there are still many investors in the running and it is not certain whether one will be invited to final purchase negotiations. The deep dive analysis goes much deeper and also provides indications of priorities after the takeover and, if necessary, initial estimates of the effort required to address problematic aspects. This level of detail makes sense if the software is a very important asset for the company and you are already negotiating exclusively with the seller.
3. Which languages can be analysed with the DETANGLE Analysis Suite?
   With DETANGLE®, all common programming languages can be analysed without restrictions.

Links

[1] Why5, “THE BUS FACTOR – WHY YOUR ‘BEST’ DEVELOPER IS YOUR BIGGEST PROBLEM”, https://www.5whys.com/articles/the-bus-factor-why-your-best-developer-is-your-biggest-probl.html

[2] Cape of Good Code, “Cooperation and Knowledge Sharing for Remote Agile Development”, https://capeofgoodcode.com/en/knowledge/cooperation-and-knowledge-sharing-for-remote-agile-development/