Skip to content
  • Development

Taking the reins: secrets to a successful project handover

April 23 — 2024

Samuel Garneau
Lead Dev & Software developer

Taking over the maintenance and development of a product whose code was not developed by your own team is now commonplace. Most organizations these days manage a significant digital portfolio and will want to avoid rebuilding existing products if they can help it. When taking on an existing project, a development team accustomed to starting projects from scratch will have to adapt its usual approach and practices. Here are a few tips, inspired by Mirego’s past takeover projects, to help you get started on the right foot.

1

Embrace discomfort

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.

2

Double up on curiosity

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.

3

Don’t skimp on the right tools

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.

4

Rely on good documentation

In a project takeover, it’s only natural to expect quality documentation that will improve the team’s understanding of the digital product. Even if the existing documentation falls short of expectations, make sure to review all available documentation on the product. It is essential to cross-validate important elements and correct the documentation where necessary.

Inevitably, some elements about the digital product will be difficult to comprehend, and no amount of documentation might help it. At this stage, just think about those who will follow and document what was learned. This approach is also likely to help the various project stakeholders gain a better understanding of the system and may bring to light issues that need to be addressed in the future.

In many ways, the main risks of a rework project are associated with the approach rather than the system itself. By focusing on code remediation while adopting a pragmatic approach, you’re much more likely to strengthen the project and avoid introducing complications. Asking the right questions at the outset paves the way for greater understanding and efficiency, averting errors while focusing on the most critical aspects of the project. Adopting the right tools early on and conducting an initial deployment provides an excellent early detection mechanism, making it easier to identify and resolve issues before they escalate. What’s more, investing in documentation early on will save you significant time and effort in the long run, allowing for easier maintenance and scalability.

Following these principles, while never a guarantee of success, significantly increases the likelihood of a successful takeover project and will turn challenges into opportunities to strengthen and improve the existing system.

00:00
00:00

En français SVP !