Sunday, February 28, 2010

Version Control - a reaction to Martin Fowler's article

Recently I've been involved with looking at how our team produces software. This has meant looking across the spectrum of activities, tools, and practices that we undertake to deliver working software to the business. It was with this activity still fresh in my mind that I stumbled upon Martin Fowler's thoughtful article about Version Control on his Bliki earlier today.

As part of my work I actually put forward an argument that we move away from using SVN for source control and to implement TFS. As somebody who has deep personal affection for the simplicity of SVN, the decision to recommend TFS was not made lightly.

In light of my own decision to move away from SVN and onto TFS, I was motivated to respond to Martin's positioning of TFS on his summary diagram which placed TFS outside of the tools that he would recommend for version control.

Whilst he suggests that TFS is not a recommendable product, Martin does not make any real attempt to explain other than to say that people he trusts don't recommend it. In this article I want to put forward some of the reasons that I chose for recommending TFS as our tool of choice.

I believe that it is unfair to look at version control in isolation because, whilst your version control software sits at the heart of your development system, it lives within a larger ecosystem. This ecosystem is made up of IDE's, Issue Tracking Software, Build Management Software, Continuous Integration Services, Reporting, and perhaps other tools and services too.

In light of all of this software that comprises your development ecosystem, consider the technology soup that you are managing. Patching and keeping these systems soon becomes a science unto itself and unless you're job is as a specialist build master where you are entitled to choose individual best of breed applications, managing this type of environment may not be for you.

Moving to TFS provides us with a single technology roadmap and vastly reduces the complexity involved in configuring and patching our environment when compared with the alternative.

An illusion of simplicity
In light of having uncovered the elements of a development ecosystem, let's reconsider our views on simplicity. First I'll start with a statement from my own observations about developing software - Developing software is a complex business. FULLSTOP! PERIOD!

As shown in my previous discussion about integration, the complexity is there always. You can have a simple version control tool but the cost of this is that you transfer more of the complexity to other parts of the system. In the case of having chosen SVN, this complexity comes in the form of having to run multiple, independant systems using multiple technologies.

With TFS you gain simplicity through technology consolidation but you pay a price for having to learn how to set up and manage it - but is this any more complex than having to learn half a dozen other systems?

The real business world
So far I've focussed my discussion about the development ecosystem on the activities of the developers themselves. However in the real business world, this is still not a fair representation of what is needed to successfully deliver working software.

Even small businesses have stakeholders that the software is being developed for and in mature businesses, there is an instrument which sits between (or straddles) the business and technology domain - this instrument is the PMO.

In light of this discovery, it is no surprise that building successful software is as much about soft skills - such as communication and reporting - as it is about purely technical pursuits such as coding, building, and releasing.

By integrating with common business software such as Excel and MS Project, the TFS work item tracking system makes it easier to align IT projects with projects in the PMO and have those functions be able to communicate using a common language.

In this article I have opposed Martin Fowler's view in relation to the placement of TFS on his summary diagram. I believe that his article is too narrowly focussed to be of real value when considering what tools to choose in creating your own software development ecosystem.

However I do agree with his closing sentiments wholeheartedly and I could not have put it any better then when he wrote:

Remember that although I've jabbered on a lot about tools here, often its the practices and workflows that make a bigger difference. Tools can certainly make it much easier to use a good set of practices, but in the end it's up to the people to use an effective way of working for their environment. I like to see approaches that allow many small changes that are rapidly integrated using Continuous Integration. I'd rather use a poor tool with CI than a good tool without. 


  1. I would even go so far to say that soft skills are the most important factor in a project.

    I agree about the integration aspects of TFS. If TFS is being used for version control then the best parts of it are being missed. Having said that though I do think TFS version control needs to be improved (in particular the online/offline story).

  2. Glad to see someone critique that article. I would go as far as to say his article and 'survey' was pure drivel.

    It was written for open source fanboys and the data came from open source fanboys.

    I've used both SVN and TFS for many years, and I don't think there is that big a difference overall. In particular, there are a lot of areas in TFS that are clearly superior :

    1. TFS merging algorithms are definitely better. Whilst this a tooling issue, I still think it is necessary to include in a comparison.

    2. Shelvesets. This is a beautiful thing, that I don't believe is possible in SVN, without branching.

    3. Integration with the task system. Being able to trigger tasks for code reviews etc is great.


    The offline/online issue is trivial. Doesn't it boil down to a simple right-click 'go online'?

    Not that I am saying I don't like SVN, that is not true and I use it for all my personal development needs but I would suggest TFS is at least on a par with SVN.

  3. Agreed that the solution for the offline/online issue is trivial but I don't think it should ask me in the first place. SVN doesn't require me to go online or offline. I would also agree its on par with SVN.

    Perhaps my issue is more with tooling along with only using it for the past 6 months or so in any anger.

    I'd love to see a similar article that compares apples to apples, say Target Process, VersionOne and TFS as I think it fits better into that category.

  4. @darren, agreed. maybe you should write that article and teach us all :-)