Pretty heartbreaking when the project we inherit from its previous devs is not covered by version control.
(By the way, this post is a quick help on how to hire developers rather than a techie rant. It’s safe to continue even if you don’t yet know what version control means.)
First of all, the way I encounter these projects is when a new client comes to us and says that they wanted to finish a project or add a feature to their app, but the original developers had disappeared. The client usually has the latest code, but has never even heard of such thing as the repository.
Not having a repository is not a disease.
It’s a symptom.
Version control can do wonderful things. It gives an overview to who, when and what changed in the source code. Whenever the developer is ready to add some changes to the app, they put those changes in a package, add a description and submit it all. A repository then contains all the code that belongs to the app, together with a human-readable table-of-contents.
Let’s pause here a bit. One look at the repository, and you can tell exactly how much the developers changed in the app’s code. It’s not necessarily enough to establish the exact hours they worked on the app itself (it doesn’t say much about the time spent on server setup for example), but, it’s certainly great insight into what’s going on with the project.
If no one touched the code for weeks, half of the features are still missing and the deadline approaches, it’s quite unlikely that everything is on track. Knowing about this well in advance is the only way to act in time.
Asking for the repository access helps with choosing the right developers as well. First, some companies are not using version control themselves, or just don’t want to provide access to it. Feel free to discard them altogether.
There will be software houses that give you access to the repository only at an extra charge. That’s fine: they acknowledge that they won’t be able to cheat with the time sheets, and it’s only fair to adjust the price accordingly.
One more point to this is that software houses like to get paid by the hour, but the hourly rates don’t provide enough insight into how good the team is. The difference between a good developer and a bad one is day and night. With the wrong team you end up getting next-to-nothing done, and spend extra hours on fixing bugs, testing and maintenance. You will almost surely be required to pay for those extra hours, which, in the end of the day just means to pay for the developer’s education.
Well, at least someone has to.