Dijkstra, tools and version control systems

“The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.”, Edsger W.Dijkstra

...or in other words...

"If you already have a hammer, it is very tempting to treat everything as a nail"

My views on using electronic tracking tools are already fairly well known. But another area that creates a huge impact is the choice of version control system. Using the right software will help your project deliver quickly and efficiently. Choose the wrong one, and the project will be nobbled by unnecessary, damaging and sometimes downright dangerous processes and maintenance overheads right from the start. 

In order to avoid the trap highlighted by Dijkstra, it is essential to match the tool to the way you develop and not the other way around. 

Let’s consider a fairly typical, highly productive and successful team. In my experience they tend to follow a fairly well defined pattern of working:

• All developers get a copy of the current mainline code out of the VCS.
• The developers work on the code, making a relatively small changes, including various tests, as they go.
• Everyone regularly checks these changes in to the mainline. This happens at least once per day. Normally checkins are much more often - 5-10 checkins per developer per day is not unusual for a fast-moving team. 
• After each checkin, the mainline code is compiled, both unit and regression/acceptance tested, and packaged. Note that assuming no problems are encountered, there is potentially deployable product each time this happens.

Regular, small checkins to the mainline branch means everyone’s code is integrated many times per day, revealing problems quickly (fail fast). The amount of change between a successful build and a problem is limited, and so makes recovery more manageable; integration issues can usually be resolved within 15 minutes. 

This way of working eliminates branching almost entirely, so avoiding the dreaded Merge Hell. Everyone always works on the mainline branch, no-one uses a separate branch to develop. Changes and bug fixes are always on the mainline, so the software is always going forward using small, manageable integrations. In the rare case that a change needs to be applied urgently to an existing release before the next formal release, then a separate branch might be created to handle this (alternatively a new copy of trunk may be deployed). Releases are, of course, fully tested at a number of levels and accepted before release, so problems should rarely occur. 

Developing this way also has “a profound (and devious) influence” on what our versioning software needs to be able to cope with. Here are just a few I can think of:

• Each automated build needs to be uniquely identifiable with minimal effort so it could be released if needed
• It needs to be easy to rollback individual changes/checkins. Fail fast also implies recover fast.   
• Checkins and checkouts need to be fast and efficient so they are seamless
• Good integration with tools to make its use virtually seamless (developer IDE, continuous integration setup and so on)
• Easy to use. Amongst the “small changes” a developer might need to do is to rearrange the project structure as required to maintain a successful develop-and-build cycle as new requirements become understood, or new components are identified

Compromising any of these would be likely to obstruct the developers as they build software[*]. Worse still, as Dijkstra suggests, the tool will affect the way developers think and work:

• If builds cannot be easily tagged/identified, then they won’t be tagged
• If it is hard to roll back, then developers will not roll back
• If it is slow to check in or check out, then developers will only do these when forced to. Frequent integration becomes less frequent, problems become harder to find
• If it is hard to integrate, build and test, then it won’t happen very often
• If it is hard to reorganise the project, then it won’t be refactored to a better structure

...to counter this, suddenly you have to issue edicts, define rules and issue development documents and ticklists to ensure people work around the bad tools and make sure the “right stuff” is happening. Trust me - I have seen it happen and experienced it first hand; it is a very bad place to be!

Whenever choosing a tool to support your project, bear Edsgar Djikstra’s quote in mind. Make the tool fit your way of working. Don’t let the tail wag the dog.

* I'm looking at you, ClearCase....