Many development teams, including Mirego’s, tend to follow the Scout Rule, which is to always leave the code cleaner than you found it. In the case of a project takeover, the temptation to do this is great. You are dealing with code written by people with different practices, philosophies, opinions, and possibly even different skills.

But the practice can quickly backfire. Without in-depth knowledge of the underlying system, you may end up compromising the code as you clean it. It is therefore essential to evaluate the impact of changes to the code. Should they prove to be too risky, it would be preferable to note potential improvements to the code and discuss them with the project stakeholders. Such improvements can be tackled later, as a more focused endeavour that everyone clearly understands.

At Mirego, code quality is as important as the quality of the delivered functionality. But when it comes to working on an existing digital product, efforts must first be focused on the result, even if it means adjusting to different coding practices.

It’s not just the person responsible for writing the code that should be embracing discomfort. Team members reviewing code changes must also accept that the usual guidelines may not apply. As a rule, code consistency should be preferred, even if it may mean repeating suboptimal patterns.

In a project takeover, it’s critical for the development team to show curiosity from the start. Invest time in learning everything about the existing product, its users and functionalities. Develop an excellent understanding of what works well and what does not work well in the product before even writing a single line of code. This advice may sound obvious, but a team usually starting its projects from scratch may overlook this step without even realizing it.

A great way to fully understand the intricacies of a product is to design and execute a rigorous test plan. This step should be included in the recovery budget, as it is essential to understanding the product and will limit regression risk when changes are made to the digital product.

Question the client and the product users. Understanding what the product does is a good start, but understanding why it does it is even better. The purpose behind a business rule is not always clear. It’s easy to assume a rule is obsolete, for example. It’s better to just ask for a deeper understanding of the product and its context. Validating all assumptions will prevent potential problems.

Once a project takeover is underway, adopting the right tools should not be overlooked. All environments should be configured, as should the continuous integration and continuous deployment pipelines as well as style validation tools (code linting). It may happen that some rules too burdensome to follow must be ignored, but having the right tools in place is a good place to start.

A swift, initial production deployment with little or no code change must be considered as a priority. The primary goal is to ensure that everything is in place should quick fixes be necessary in production. This also ensures that nothing is broken in the existing system when configuring tools and environments. We don’t want the first production release to contain major changes. The bigger the change, the harder it is to identify the cause of problems or side effects. 

The team might notice the need to run some commands manually several times daily or weekly. In that case, make those commands available to everyone via a Makefile or equivalent solution. This will help all team members save time and avert errors.