By Stuart Smith, Product Engineer, Saritasa
In an ideal world, the developers who start to code software project would finish it and maintain it. In the real world, a variety of factors can force a new development team to come in mid-project. This is often referred to as a code takeover or project rescue.
What Causes Code Takeovers?
When a project starts, people wear rose tinted glasses. Minor issues are overlooked. Red flags ignored. But as a project goes on, those issues become more prevalent.
Sometimes these problems are huge. The development team doesn’t deliver what was promised. The software is riddled with bugs and barely functions (if it runs at all). Change orders pile up, and budgets far exceed expectations.
Other times, it’s more gradual. Perhaps project development went smoothly, but there were issues with the final release. As the project enters maintenance, new features and bugs are treated with lower and lower priority. The current team no longer meets the demands of the product.
In some situations, it’s simply a matter of time. As technology stacks age, developers switch to newer languages. Older programs struggle to find proper support.
Whatever the reason, the result is the same – the need for a code takeover. The key to a successful code takeover is preparation.
Preparing for the Code Takeover
A smooth transition between developers depends heavily on preparation. While an amicable split from the previous developer is preferred, it’s not always possible. However the relationship ends with the previous developer, well-organized requirements makes the transition significantly smoother.
Before initiating contact with a new developer, secure the source code in an environment outside of the previous developer’s influence. Access to the source code (not the compiled code) is the most critical part of a code takeover. Without the source code, the new team has nothing to build off of. In most cases, a repository such as GitHub hosts the source code. Alternatively, it may be stored in a recent archive.
External documentation and code comments, if not already included in the source code, are also helpful. Lastly, a walkthrough of the development, staging, and production environments can get the new team up and running much faster.
When possible, it pays to maintain open and friendly communication with the previous developer. If the new developer has questions, they can be a valuable resource for quick clarification. A code takeover can be successful without the collaboration of the previous developer, but it certainly makes the transition smoother and faster.
What Determines Code Quality?
Any reputable developer will begin with a code review. The purpose of this review is to determine the code quality, which will affect the effort needed to onboard a new team to the code. A code review typically assesses the following;
- Base-Level Functionality – Does the code compile without errors? Is it modular? Does it conform to proper conventions and follow best practices?
- Tech Stack – What language is it? Is the team familiar with this stack?
- Performance – Are there any performance issues? I
- Security – Is the data encoded properly?.
- Scalability – Is the code architectured to scale?
- Documentation – Does the code have comments? Are these comments easy to understand? Is there external documentation?
- Test coverage – What tests have been run? Can the code be tested?
An easy way to demonstrate the results of this assessment to those who may not be technical is via a five-star rating system. Code varies dramatically in quality, and may perform better in some areas than others.
The Code Review Results
The results of a code review typically falls into one of the following categories;
- Good Quality Code: If the code is acceptable and of good quality, the new development team can start to work right away working on enhancements and bug fixes. Good code is well-structured, well-documented, modular, and uses the latest technology stack.
- Poor Quality Code: If the code is poor quality but fixable, a decision needs to be made. The new developer can take it over, but may take time re-writing chunks to make it easier to understand. Poor code lacks documentation and comments, and may not be well-structured. It likely requires some amount of re-writing the existing code before adding new features. Sometimes sections can be refactored as needed. But is fixing the current code worth the time and effort investment?
- Unworkable Code: Occasionally, the code is so poor as to be unworkable. If blocks of undocumented code are poorly written, or the code uses an outdated technology stack, starting over is the best option. Ultimately, it will take less time, and will result in a higher quality product that performs better and is easier to maintain.
Finalizing the Code Takeover
The code review is done. The quality assessed. Now to finalize a transition plan. This starts will setting up environments, often consisting of development, staging, and production, along with a code repository. All this must be set up before they can begin work on the code. In fact, depending on the state of the source code, the developers may need to refactor areas of the code before they can address bug fixes and new features.
Development time may be longer during the ramp up period. It takes time to get up to speed on someone else’s work. Often developers need to clean up the code as they work. Experience shows that it’s better to approach smaller tasks with isolated sections of code. This approach makes it easier to learn new application structures and reduces the risk of correcting one problem that creates an issue somewhere else. As the new developers become better versed with the source code, they will be more efficient and be able to make changes faster as they become comfortable with the code structure and refactor the code as needed.
Switching development teams mid-project may sound scary, but sometimes it’s for the best. Initiating a code takeover doesn’t have to be difficult. With the good preparation and the right partner, a code take over could save the project.
