Time for a Code Takeover

A Code Takeover is when a company develops a software application using a software development firm and then wants another firm to take over the development of the software. Or maybe the firm is going to bring the development in-house and take over the development of the application themselves. This can also be known as a Project Takeover.

Why Switch Development Firms?

It happens all the time. There’s often a multitude of reasons why a client would want to break off their relationship with their developer.

A company hires a software development firm to develop a software application and becomes disenchanted over time. Or the company used a freelance developer and they have outgrown the capacity of a single developer. The actual project development may run smoothly, but problems pop up when the application releases. Projects built without using best practices for quality and scalability may experience a never-ending stream of bugs and performance issues. Development organizations can shift priorities. Response time for communication, bug fixes, and enhancements can suffer if your project is not a priority.

Relations can sour over time for various reasons. If that is the case then it might be time for a code takeover.

Friendly or Hostile Takeover?

Assuming development of a software application can be easy, or very, very hard. That sounds like a line out of a bad movie, but it is truly the case with code takeovers. They can be hostile or incredibly smooth.

First things first, you NEED to have access to your SOURCE code. Not the compiled code. The SOURCE code. In most cases, a repository, such as Github, holds the source code. You may also have a recent archive of the code. You will need to have the access to the most recent source code for another developer to assume the development.

Hostile code takeovers are obviously more difficult. If the previous developer of the application is angry and unprofessional it can make the takeover process much harder than it needs to be. Maintain good communication through the takeover process if at all possible. The process can be much longer if the developer is unwilling to provide any documentation and doesn’t want to spend time turning over the code to the new team. The new team must spend more time learning the code structure before they can become productive.

An amicable split with your developer will make the transition to a new team significantly smoother. Documentation, in addition to code comments, allows the new developers to come up to speed on the application much quicker. If the developer is open to providing the new development team with a walk-through of the code and the development, staging, and production environments it can greatly decrease the time it takes the new team to become productive as well.

The Code Review

At Benjamen Glover LLC, we perform a code review on any project before we agree to take on the work. We do this so that we know what we are getting ourselves into with regards to the quality of the code that we will be working with. The result of this code review normally goes one of three ways:

Acceptable/Good Quality Code

The code is of acceptable quality and we can start work on the code as is to fix bugs or make enhancements. This is the best-case scenario. The code is well structured, well documented, modular, and uses a current technology stack. If this is the case, we can start work on the code directly without refactoring or spending much time coming up to speed. We can be efficient in making changes to the code right from the start.

Poor, But Fixable Quality Code

The code is of poor quality, but we can work with it. Sometimes the code is not really up to snuff but is not bad enough to rewrite it from scratch. We see this frequently where the code is not great, but not horrible either. Typically, this includes code that is not well documented or commented. In this case, we need to spend more time figuring things out before becoming productive. Many times, the code is not well structure or was not developed using best practices.

We may need to refactor (rewrite) some of the code before we begin to develop new features. Sometimes we can refactor as we go, meaning we can rewrite areas of the code as we add new features or fix bugs in those areas. With the code in this state, we work less efficiently at the start of the process. but become more efficient as time goes on and we rework the code into a better state.

Unworkable Quality Code

It is bad, like really bad. On occasion, we will run into a situation where the code is horrible and not something we will be willing to take on. It does not happen too often, but it does happen. We have seen very large blocks of code that were very poorly written and contained no comments whatsoever. Sometimes the code is just so bad or uses a technology stack that is so outdated or foreign to us that it just would not make sense to try to fix it.

The only option may be to rewrite the code from scratch. For smaller applications, this might not be such a bad thing. You will ultimately end up with a much higher quality product in the end. If this is a large application, it can be very costly to rewrite it. However, all may not be lost. You may be able to use your existing user interface design and product as a specification for the rewrite. This saves a lot of time normally devoted to wireframes, design, and planning.

What Determines Code Quality?

When we do a code review, we have several factors that we consider. These include:

• General Quality – Does the code compile without errors? Does it conform to proper conventions? Is it modular?
• Tech Stack – Is the technology current? Are we familiar with it?
• Performance – Are there any obvious areas that could cause performance issues?
• Security – Is the data encoded as necessary?
• Scalability – Does the architecture support scaling easily?
• Documentation – Is it commented? Do the comments convey the intent of the code? Any external documentation provided?
• Test Coverage – Do tests exist? Is the code testable?
• Overall rating – 5-star system

The Code Takeover

You have decided to allow someone else to develop your application. Now comes the time to turn the code over to the new developer and allow them to get started.

As discussed earlier, it makes things much easier if it is a friendly code takeover. If this is not the case, the new developer will probably need a little time to study the code before they start work.

In any case, the new developer will need to set up their development environment (code repository, development server, and possibly a staging server). Once the development environment is set up, they will build the process to deploy new code to production.

Depending on the state of the code the developer may need to refactor areas of the code before they can begin work on bug fixes or enhancements.

Once work begins the developer may be less efficient depending on the state of the code. This means that bug fixes or enhancements might take a little more time to finish until the new developer comes up to speed or cleans the code up. Once the developer finds their grove, they become more efficient and can deliver results at a faster pace.

The Saritasa Code Takeover Process

At Benjamen Glover LLC we have found that it is best to start with smaller tasks in one isolated area of the code. This allows the developer to learn the new application structure and runs less risk that a fix in one area might break something in another. If the developer can focus on smaller areas of the code to start and then branch out into other areas, they can learn the code quickly with little risk of introducing new problems while trying to fix bugs or make enhancements.

Over time as the new development team becomes familiar and refactors code as necessary, they will become much more efficient and be able to make changes quickly with fewer development hours.

So, if you are not happy with your current application developer or you have outgrown your developer’s capabilities, maybe it is time for a code takeover. Give us a call if you are considering a new developer, we can do a code review and see where that leads