Why developers don’t use a Version Control System (CVS, SVN, Git, Hg, …)?

Jack woke up early that morning, he goes to the kitchen and found it in a total mess. All things on the floor; his clothes and documents too; by that moment he already understand what happens, his house was robbed!

Among others things, he quickly notice that his laptop was missing too. And here comes the real problem, on the HD he had the sources of various application he owned; applications already sold and with maintenance contracts. He did not made a backup somewhere else.

After that incident he de-compiled an old version of the application. He also needed to update / rewrite some modules because they were not working as the production version. Also the decompiler output some code as assembler code.

By the same week he start using a Version Control System, with a web provider.

• Time working without version control system: ~3 years
• Time working with version control system, after a big loss: almost immediately

Peter had worked as developer for almost  8 years, he has never used a Version Control System. At his actual Job a project was conceive to adopt a version control system. All developers were trained, all software was installed and a new corporate policy was created to enforce its use.

A year and a half after project completion, Peter still did not use the Version Control System, he just made the code changes and upon requests he upload the final version of every requirement to a branch. He also find himself with a bunch of conflicts because he worked on a very old code base and never gets the new one.

Recently he started a personal project, some software product he believe will be very popular and generate some sales. He start working with the same methodology: manual backups, total application rewrite because of code lost, inability to revert to a stable version after a big re-factor, among other bad practices. By the second week of work he, voluntarily, starts using Git.

Company A (the Client), hires Company B (Software Vendor); to implement a new system. The relation include a full development effort of the vendor; and a mentoring period to local (at A), resources to gain experience on the new system and continue its maintenance labor.

After months of work, on his facilities, the vendor finished the work and the user acceptance tests (UATs) began. At this point the problems start to arise. Every time a bug or problem was reported and the vendor starts working on it; another functionality gets damaged. When the root problem was tracked a guilty was identified: the vendor was not using any versioning tool; so they just get the last “stable” sources from disk and start changing it. After they finished their work they fix the reported bug; but introduce a new problem on another functionality. This can be addressed with  a good set of automated tests, but you still will have the problem of code lost over time: they can’t just rollback to a known stable version.

The problem with our first case, is that he never felt the necessity to use a tool to control software versions until he suffer a source lost because of a house rob. His bad practice never gets punished.

Our second case, has the same root problem. On his past jobs he was never forced to use a versioning tool. So he just does not care about it. But, wait on his actual job exists a policy to use a tool. So why he does not use it? because the policy does not include any admonition to be applied when people do not follow the rules.

The third and last case is more of the same. The client company does not include on the service contract a section of regulations or procedures to be followed by the contractor. If the contractual obligation had existed along with a set of repercussions for the software vendor, the later will not be incurring on the flaws described.

If forever reason you are new to versioning tools, here you have a short list of tools including the most popular, they all are free: