How to prevent unwanted surprises with a technical due diligence audit

Why is technical due diligence needed?

Eficode has been undertaking DevOps and software audits for many years now. During this time we have seen multiple cases where business critical solutions have been in such a bad state that the only way to progress forward is to rebuild from scratch.

We have also witnessed the worst case scenario where rebuilding would be such a big, expensive effort that the business income is not able to cover the required additional  investment in any reasonable time.

For the last three years Eficode has been also providing technical due diligence (Tech DD) audits in order to help investors understand the state of business-critical applications. 

In this blog post we will discover some of the most typical reasons behind the poor state of solutions, how we conduct technical due diligence, and estimate the expected near-term financial impact.

“Working software” is a delusive statement. For example, software might be working as usual for its users, while there may be a host of hidden technical problems behind the scenes. Indeed, these problems can be so serious that the software requires immediate additional investments just to keep the business running. 

Technical debt and other typical challenges

Wikipedia defines technical debt as a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. What makes it more difficult to understand is that technical debt is typically a hidden and abstract attribute.

Why would anyone choose to use shortcuts in software development, you may wonder. Put simply, the answer is because optimal approaches require more time and costs. 

While rushing during the development phase due to deadlines and financial pressure is common, they are not the only reasons for technical debt. This also builds up when:

• Products are extended into directions they have not originally been designed for.
• Infrastructure, library or framework updates are neglected.
• Quality issues are neglected for prolonged periods.
  

Technical debt covers many problems, but other major challenges can also be present within the applications or company. These include:

• The chosen technology platform being deserted and is therefore no longer receiving security updates. This makes finding motivated developers increasingly difficult.
• Non-scalable architecture or technology selections are preventing future expansion.
• Licensing issues requiring immediate investment either upon licensing or reimplementation.
• In-house knowledge gaps limiting development speed and potentially lowering quality.
• A lack of proper development processes and DevOps practices as an impediment for scaling of the development team, also affecting quality.

The ultimate consequence of poor state of software is that the efficiency of new development goes downhill until it reaches a point where nothing seems to get done, as circulating and tackling problems eats up all the developers’ time.

It is at this point where end-of-life decisions typically need to be made, and continuing the business requires restarting development from scratch.

The technical due diligence process

Eficode’s technical due diligence is a professionally conducted software audit that takes due diligence aspects into account.

We hold discussions with the investor(s) in order to understand future targets, so that we can verify the current system’s capabilities against them. 

Stage 1: Review the current system

The starting point for a technical due diligence audit is to review the target company’s existing documentation and go through their currently used development setup. 

The key to get to the bottom of everything lies within access to the version controlled source code. That holds the ultimate truth, and is not something that can be easily disguised in the hope of investment. 

Since the amount of code in this can be large and time is limited, we use automated tools to identify potential problem areas in the code. Automated findings are then complemented by our experts' view on architecture to form a list of targets for the Eficode team to dig into. 

Stage 2: Conduct interviews

We build on our understanding of the used system, processes and tools by interviewing people at different positions in the target company. 

These interviews also help us to form an understanding of the team’s knowledge, potential knowledge gaps, and identify key persons from the development point of view.

Stage 3: Outline findings

Finally, we will write a report outlining our findings and Eficode’s view of the current technical state of the system. 

Findings are typically numerous and complex in nature, but we will summarize and clarify what is vitally important, and what is less so.  Furthermore, we provide recommendations of how to improve and from where to start. 

In custom-made software systems there is a good side, in that you can typically improve things, but this requires time and money. Focus on software sustainability – is there a big investment waiting in the near future? Is it required for extending the lifetime, or enabling scaling of the targeted business? 

Expected immediate cost impact

From the results of the technical due diligence we will provide a monetary ballpark of the expected immediate cost impact to cover the now-visible technical debt.

We classify this into five numbered categories – where 1 indicates excellent system health and 5 means the system is beyond repair.

Know what you are letting yourself in for

In this time of tech acquisitions, proceeding without undertaking technical due diligence would be like opening Pandora's box. It is quite likely you will find technical debt slowing down development and requiring additional investment – but how much is that likely to cost?

You should always find out before making any decisions.