Finish Your Software Project Without Starting Over

No software development project is fully without complications. Sometimes it can be as simple as evolving specifications, while other times it may be as momentous as losing your initial developer. Losing a developer doesn't have to be the end of the world; you just need to find the right developer. Choosing a developer to takeover a project can be substantially different from choosing an initial developer, as the skill set that is necessary differs.

The Challenges of a Takeover Project

Many software developers are wary of taking over a custom software project that has already been started. Not only do they need to figure out the project (often with very limited documentation), but they are also in the undesirable position of potentially being blamed for another developer's shortcomings. A project can move ahead six months only to find a fatal flaw in prior development -- a flaw the new developer may easily have to take responsibility for. Or worse, the code base is a snarled mess of poor design and bugs that got the original programmer fired in the first place.

With a partially built solution, you need to find a developer who is knowledgeable and experienced enough to view your custom software solution and run with it. They must be able to build off what already exists in order to fully visualize your completed solution, which often requires a significant amount of time and study.

Aspects to Look for in a Developer

Though there are many factors involved in completing a partially built software project, your developer is going to matter the most. It is your developer (or development team) that is going to control the transition, and it's their personal experience and knowledge that's going to ensure that the project continues smoothly.

Here are a few aspects to look for in a developer:

• Knowledge and experience. Building out custom software from a partial build is challenging. A developer should have substantial knowledge and experience in both the language and platform the custom software is being built on. The more experience they have, the easier they will find it to piece through the code that you already have to figure it out. It's easy to assume that a developer could be less experienced because "some of the work is already done," when the opposite is true: you need a more experienced developer to take an already existing project and run with it.
  
  
• Communication skills. A developer needs to understand the project inside and out and needs to be able to communicate any issues or questions they have. A developer who stonewalls you or who isn't able to articulate their needs isn't likely to be successful. When dealing with a partially built solution, a developer is going to need to be aggressive about anything that they don't understand or that isn't documented. They also have to be able to capture and document your needs so that in the end you get what you want.
  
  
• QA capabilities. Often, the software developer is going to have to begin their work by checking the work that was done by others. This isn't a skill that every developer has. Some developers are better than others at piecing together code that they haven't personally constructed. Other developers may need to be handheld through the process and may need additional time to figure out the existing development. Development teams, as opposed to a single independent developer, usually have dedicated testers trained in QA.
  
  
• Staying power. You naturally want to choose a developer who is going to be able to grow with the project; you don't want to bring in another developer next year. Look for developers who are looking for a long-term commitment, who are excited about the working environment, and who seem uniquely interested in the product or services that your organization provides and that you need to build custom software for.
  
  
• Doctor’s rule: “Do No Harm”. Taking over maintenance of a system that is already in production can be a delicate operation. Care must be taken when working on a live system to prevent costly downtime.  Also, only experience can tell a developer when it is best rewrite vs. patch. Junior developers usually want to rewrite everything thus running up a big bill. Whereas a seasoned developer may determine that it is in the companies best interest (and budget) to simply patch or work around a given problem thereby freeing up budget money to focus on more important issues.

If you can find a solid developer, a significant amount of the battle has already been completed. A good developer will be able to pick up the pieces that were left for you and will be able to develop your custom software with as little repetition as possible. At the same time, a bad developer may simply leave you in the same position later on. It's worth it to be careful and cautious when choosing a replacement web developer.