Here at ClearSky Logic, we have a wide range of skills and services which we offer our clients. One of our newer services is a “Technical Audit”. In this article we will be exploring what this is, how we go about it and some of the reasons that you might want to engage us to carry out a technical audit for you, so let’s dive in!
Why?
One of the main reasons that we get asked to carry out a technical audit is for due diligence. Prior to investing, investors carry out a thorough audit of all aspects of a company in order to assure themselves that they have all the necessary information to value the company and ultimately decide whether or not to invest. For technology companies a key part of due diligence is a review of the technical operations to ensure that the company can execute going forward, particularly considering the challenges of scaling that new investment can bring.
As well as due diligence, another reason we get asked to carry out technical audits is in order to help teams identify ways to improve their ability to execute. The insight that we bring to the table can be invaluable to teams of all sizes and capabilities. We bring a fresh set of eyes and new perspectives and so we always have loads of ideas and suggestions to improve your team’s ability to do what they do better. Next up, let’s look at what a technical audit involves.
What?
We break down technical audits into three major parts:
- Development processes
- People & Skills
- Technical quality
Let’s take a look at each in turn…
Development processes
Development processes encompass everything from the identification and refinement of new features to the delivery of working software to customers and everything in between. Good development processes mean that teams can rapidly deliver the features and improvements that the business needs with confidence. Conversely, if development processes are lacking then we might find that it takes a long time for the development team to align on what is required, build a new feature and have the confidence to deploy it to customers.
At ClearSky we have established development processes which work well for us and our clients. However, we recognise that there is no “one size fits all” and so even similar teams in similar sectors might have different processes which work equally well for them. Therefore, when reviewing a team’s processes we don’t assess them against the “ClearSky way”, we look at how effective they are for the teams using them. It is all about results. It doesn’t matter how your team works so long as the processes support everyone to do their best work and allow the team to deliver a quality product on predictable timescales.
People & Skills
Another key part of a technical audit is a review of the team’s composition and skills. Do you have the right people for the job? Software development is a very broad field and it can be applied to solving an almost limitless range of problems. Businesses, especially startups, should have focus. Your business will be using a particular set of tools to solve a particular set of problems. You must have the right people with the right skills and experience to execute.
Technical quality
The last, but most complex, part of a technical audit is the quality of the software. This can be hard to measure but we do our best to keep it objective. Let's dig into some of the key aspects of technical quality:
Architecture
Software architecture can be a very opinionated field and it is a hot topic. The saying goes that if you ask 100 software developers how to solve a problem they will give you 100 different answers! Although there are often no clear “right” answers, there are some principles that almost always hold true such as simplicity For example, is all the complexity of a microservices architecture the right choice for an early-stage startup which has a small team and a few dozen customers? Probably not.
Although there are very few right and wrong answers, there is one principle that we believe always holds true: The architecture of a software system should be clear and consistent. A code base becomes difficult to maintain and develop if, at each turn, different patterns and approaches are taken for no good reason. Consistency breeds familiarity which in turn allows developers to “move through” a code base easily without continually dealing with the mental overhead of understanding new and unexpected ways of solving similar problems.
Testing
At ClearSky we believe that a solid testing approach is absolutely fundamental to delivering quality software. It may be tempting to skip testing in the early stages of a software project and this might save a bit of time in the short term. However, in the mid to long term, the lack of tests will slow down the ability of developers to change the system with confidence. A good test suite gives developers assurance that the changes they are making haven’t broken any existing functionality. This is critical to maintaining a healthy codebase that can continue to grow and adapt to the needs of a business over time.
Testing comes in many forms from simple, quick, reliable unit tests to end-to-end tests that are complex to write and slower to execute. Whichever type of testing is employed in a project (and there should definitely be some!) we strongly recommend that the tests are automated as far as possible so that they can run regularly and catch issues early. Manual testing also plays an important role, particularly exploratory testing, however, it has limitations in how often it can be done, its cost and the risk of human error.
Dependencies
The choice of which dependencies to use and what to build yourself is critical in all software. When you take on a dependency you gain the benefits of speed - you don’t have to write the code yourself - but you lose control over the code. This exposes you to the risk of issues in the dependency taking a long time to resolve or even the dependency going out of support. Conversely, when you write code yourself you gain complete control over it but this is a significant time investment both upfront and in the long-term maintenance.
Ultimately, the choice of dependencies should be driven by the business goals. What are the novel parts of your business that are unique or where you are trying to outperform the competition? You should probably write these parts yourself and take dependencies for everything else. For example, you probably want to find someone else’s battle-tested code for your database communication and logging but you’ll want to write your own code for the hot new booking efficiency algorithm that is going to revolutionise mobile workforce management (hello https://www.bookinghub.ai/!).
Security
Security is critical in all software. At its core, security is about making sure that only the correct people can see and do what they need to. Security is often a major dependency in a software platform, and it should be. Millions of software applications have the concept of users who can log in, reset their password, recover their account etc so why reinvent the wheel? Unless you are doing something truly novel in this space we would expect that this complex and critical functionality is left to a well-established and trusted third party.
Observability
This is an often overlooked aspect of technical quality. Observability is about the ability to understand what is going on inside your application when it is running in production. When developing software on their machine it is easy for a developer to inspect code, set breakpoints and step through the code. However, once deployed to a server in the cloud, it suddenly becomes much harder to diagnose problems and unexpected behaviour. There will inevitably be issues in production that your customers will find, this is unavoidable. It is never good when a customer finds a problem with your software but most customers will be left with a positive experience if you can quickly identify and resolve their issue. Observability is what allows you to do this.
How?
So how do we go about carrying out a technical audit? Key to our technical audit process, and all our work at ClearSky, is communication. We pride ourselves on being excellent communicators. The first stage in a technical audit process is to have a conversation with the people who have commissioned the audit in order to clearly establish what they hope to get out of the processes. Often our key stakeholders in Technical Audits are non-technical and this is where ClearSky’s strengths come in. We believe we are second to none when it comes to understanding complex and technical problems and communicating them in a way that everyone can understand and discuss.
Communication is also essential as it can be a bit unnerving for a team to have a third party come in and ask a lot of questions about how and why they do what they do. In order to get the most out of the technical audit process we need everyone’s cooperation and involvement. We know that the operations and sales teams' experiences and views are equally as important as those of the technical team and so a key goal of the technical audit is to understand both sides and analyse how effectively they meet in the middle.
Now let’s walk through the typical stages of our Technical Audit process. The first stage is to gather all the relevant existing information that we can. We will ask for any diagrams and documentation that you have, talk to the team to confirm understanding and fill in the gaps where necessary.
Next, we will review the technical aspects of the system including the code base, infrastructure CI/CD pipelines, to get a finer-grained understanding of how the system works. We will also sit down with as many technical team members as appropriate to discuss the team’s processes and understand the background of the key technical decisions that have been made.
Once we have gathered all the information and spoken to everyone necessary we will create a draft report with some initial conclusions and recommendations. We then like to share the draft report with key members of the technical team in order to sense check it and provide an opportunity for feedback and clarification.
After this, we will prepare the final report. This will include a thorough snapshot of the system as well as our conclusions and recommendations:
- Executive summary - containing a summary of the key findings and answers to the specific questions to be answered that we identified at the start of the process.
- Existing features - a description of the functionality of the system.
- Limitations - a description of key features which the system is lacking.
- Technical - a description of the architecture, code, deployments and testing.
- Recommendations - the conclusions that we have reached and recommendations that we have, all backed up by the evidence presented in the earlier sections.
- Appendices - diagrams and supplementary documentation.
As mentioned at the start, one of the main reasons we get asked to do a Technical Audit is due diligence for investors. However, our primary goal with all technical audits is to use our fresh perspective and wide experience to provide useful, actionable insights when making important decisions. We believe that this kind of process can be useful in many scenarios, not just for investors.
We strongly believe that you will find our recommendations to be relevant to your business and worthy of implementation and we can help here also. After a technical audit, we are always happy to discuss how one of our Special Ops software delivery teams can help take our recommendations forward to rapidly realise their promised benefits!
