Switching Software Developers
 

Your current developers

Your current developers should have a source code control database (SCC) that allows any number of developers to work on the code at a time. They should also be willing to show you how to use it so that you can see the source at any time (assuming you have been paying on time). The code that is committed to the SCC should compile without problems and therefore you can hire additional developers at any time. If your current developer does not use an SCC or is reluctant to provide access, or reluctant to provide a copy of the source code, you should be concerned. Basically, if they are not willing to let you go elsewhere, then you really should go elsewhere. Here are some excuses to watch out for.

The new developers

The new developer should not spend several hours reading the code to get to know it. They should follow these steps.

  • Get the code and sample database and build the application. Within a few labor hours the new developer should be able to deliver a version of the application that they have built. If it is a website, then the website should be running on some test server that you can use to prove that the developer has gotten all the required components and gotten it to run.
  • Use Source Code Control. The current developer should be willing to include another developer on the project and should have a source code control system that allows multiple developers to work together. If they are not, you are doing the right thing to switch to another developer. The new developer should set this up and be willing to include your current developer in the system.
  • Review the code. The code should be looked at for an hour or two to get a general feel for how it was developed and look for common problems. The new developer should be reluctant to throw out the existing code. (See an example where we have thrown out the existing code.)
  • Fix some easy bugs. Once the developer has proven that they can build the software, they should start fixing bugs. They should work on the easiest bugs possible and move to harder and harder bugs as they get more familiar with the code. After a while, they will have a feel for what the software does and what you want the software to do and they will be able to make estimates and provide guidance on how to proceed for the long term.

"The code is not stable." If your developer doesn't use an SCC, then they might not see how it is possible to let another developer modify the code and they will claim that it must be "stable" before they hand the code over to someone else. This excuse could also mean that they are in the middle of changes that are taking a long time to finish. Developers should avoid these situations.

"It needs to be documented." Usually software doesn't need any documentation. The new software developer must figure out what the application does, and then they will have no problem figuring out how the code works. Most developers will attempt to figure out what the software does by reading the code. This is difficult to do and when the developer has problems figuring it out, they will blame the code and tell you it needs to be rewritten.

One of our customers came to us frustrated in the lack of progress by their current development firm. We discussed their business plans and therefore had a good understanding of what we expected to find in the software. Unfortunately for the customer the code was not usable. The previous developer did what we call "copy/paste". The developer copied existing code to each page that needed that look instead of referring to the single source for that look. This is fixable, but the database schema was incapable of handling their needs. Both of these problems meant that all the code would have to change significantly, and that meant that there was nothing to gain by using the existing code.

The customer came to us because he could tell they were not creating the functionality that he wanted. The developer did not understand the general business goals and therefore could not properly interpret the customers detailed instructions.