As I said in an earlier post, version control seems to have moved forward a long way in a relatively short time and I feel like I’m lagging behind. In previous project I’ve worked on we’ve used Sourcesafe and TFS. Sourcesafe is now universally reviled – no real support for branching(!), it’s possible (well, really easy) to permanently delete files that actually makes rolling back to old versions impossible, an apparent limit of 5gb, and worse of all it occasionally decides to corrupt your files. It’s easy to find articles from as far back as the early 2000’s warning of the dangers of using Sourcesafe.

Having said all that, I’ve had far more problems using TFS than I ever experienced using Sourcesafe. Having thought I was making a big upgrade from Sourcesafe, it came as a real shock the first time I needed to roll a project back, and realised there apparently no way to do it. It’s hard not to lose faith in a system when you have to install extensions to perform what I’d consider one basic functionality. TFS also seems to be built on an incredibly confusing model – I still regularly finding myself getting the latest version of some code, then having to get the latest ‘specific’ version. I have no idea why.

Worst of all TFS is slow. Really, really slow. And trying to use it whilst you’re having network problems is a joke – you might as well shut your machine down and get a coffee – there’s no way any works getting done if you’re not connected.

So if I’m not using TFS (and I’m wouldn’t be even if it was the best option out there – it costs a fortune and it turns out all the better choices are free or close to free) what are the options? Developers I’ve worked with swear by Subversion and maybe a couple of years ago this was a valid choice. But everything now seems to have moved towards Distributed Version Control systems, and Subversion is stuck in the old model of having a single, central version of the code.

What does a distributed version control system give us? Basically it means that as a developer I have my own independent copy of the entire history of the project. It exists locally on my machine, and there’s no need to connect to a server whenever I want to do things like check-in changes or rollback to earlier versions of the code. In the old, non-distributed, model I had to code locally and (ideally) make sure my code was bug-free before inflicting it on the other developers. This meant it was often the correct decision to work locally for long periods of time – in other words you’re encouraged to code without using the benefits of source control.

Distributed systems mean you can check-in without fear of breaking other developer’s systems. Each time you reach a sensible point you can check-in your work into your local repository and it has zero impact on other developers. Once you’ve completed a piece of work you can push from your local repository to the central repository, and request that other users pull it down to their local repository.

The second obvious benefit to localised repositories is speed – because there’s no need to talk to a server (unless you’re pushing to or pulling from the central repository) everything happens locally. When the network goes down, or you decide to do a bit of coding on a plane, it has no impact of your ability to work and carry on using source control.

There seem to be two good choices for a distributed version control system – Git and Mercurial. I’ve installed a played around with both to get a feel for both of them, and honestly there doesn’t seem to be much to differentiate them. The general consensus seems to be that Git is marginally faster, but Mercurial has a more mature toolset especially if you’re using Windows and want to integrate with Visual Studio and an easier learning curve.

I’ve read a ton of articles comparing both systems and there doesn’t seem to be any clear consensus over which is superior. Git ‘feels’ more modern and has complete manual online for free (http://git-scm.com/book). It was easy to install tooling for both – tortoisehg for mercurial (http://tortoisehg.bitbucket.org/) and git extensions for git (http://code.google.com/p/gitextensions/). I’d tried Fogcreek’s flavour of Mercurial called Kiln (http://www.fogcreek.com/kiln/) which was pretty slick, and is free for startups, although probably quite pricey to add additional developers. It as pretty fantastic visualisation of branching (the wonderfully named ‘electrified dag’) and integrates nicely into Fogbugz, a bug-tracking system I’m fairly keen on using). Git is free for open-source projects, although as I want a private repository for this project I’ll have to fork out $7-a-month if I want to host from Github (https://github.com/).

In the end I’ve decided to go with Git. With source control up and running, it’s time to start building.

Although I don’t want to go too deeply into what I’m going to be building, I can still talk about the what the options are for technology I’m going to build it with.

First are some givens – I’m going to write in C# using Visual Studio 2010. There is already going to be a substantial learning curve in this project – I’m not going to make it any tougher by trying to learn Python on top of everything else. Plus I enjoy writing C#, I genuinely like VS2010 as an IDE, and one of the primary goals is to improve my coding in .NET by catching up on ASP.NET MVC. They’ll be opportunities to play around with a second language later.

From all accounts MVC has pretty much emerged as a clear winner over webforms for any non-trivial project. It solves a number of problems that have plagued Webforms – mainly caused by the way Webforms attempts to abstract away differences between web and Windows development. It’s been a constant struggle in project’s I’ve previously worked on to manage the size of Viewstate, the way webforms tries to mimic state on the stateless internet. I’ve never really suffered from the postback model adopted by webforms (it actually hurts a bit to have to throw this knowledge away), but MVC apparently massively simplifies matters by following the HTTP verbs (POST, GET etc).

What else? The big benefits I see to using MVC is that is allows (enforces?) a clean seperation of concerns. Every project I’ve worked on so far has had a really problem mixing the business and presentation layers – it’s easy to see how MVC can help with this. Automated testing has also been an issue with every previous project I’ve worked on (mainly due to the difficulty of unit testing the presentation layer) and MVC seems to work hand-in-hand with Test Driven Development.

The final difference that’s important to me is the level of control MVC supposedly gives you over the markup that gets generated. Coming from a webforms background where you have almost no control over the HTML and Javascript that ends up on the page, I’m hoping this will eliminate the occasional day spent hacking together CSS rules because a control is a pixel too wide in IE7.

There are supposedly a bunch of other benefits – but those are the one’s I really care about. More control over the output. A pattern that enforces better coding through a separation of concerns. Easier maintenance through automated testing.

With that decided, I just have to learn it now! One thing I’d really like to try is fully abstracting the business (and data layer) away from the website by building the business layer completely in isolation. I’d like to try constructing it in it’s entirety before building the website on top of it. Because I have a pretty strong grasp on the model of the project this might help avoid some of the compromises that start popping up when you’re creating parts of a website one-by-one and expanding all the layers of the project in parallel. I have no idea if this is practical or not – it certainly might be tough to work on a project for a few months before seeing the first pages in action.

For a while now there has been a development project that I’ve wanted to try my hand at, and I’ve decided that it might be the right time to give it a go. Although there a lot of things I like about my current programming job in Amsterdam, there are also a lot of things that I find frustrating. Chief amongst these is that we use relatively ‘old’ technology – although in IT by old I mean ‘about 2 years old’. This is just a compromise of working on a legacy system – as much as I’d like to rewrite our software using all the latest stuff, we have a large customer base to keep happy, constant maintenance that eats up our time, and we’ve invested large amounts of money into licences for software that, irrespective of current trends, we’re going to be using for the foreseeable future.

The problem is that even more than most industries if you’re not on top of the current trends as an IT professional, your CV starts looking outdated real fast. When I moved to Amsterdam on short notice my CV was extremely current – I’d been developing on the .NET 2.0 beta with a team running Scrum, just as Scrum was becoming the latest fad word that showed up in every job advert. The result was that I had a really easy time finding interesting jobs, and plenty of offers to choose from.

Four years later and I’m getting worried that my current job is too comfortable, and it’s going to make it difficult to ever leave. Webforms have become obsolete in the intervening years – MVC has matured (MVC 4.0 is currently in beta!) and has too many advantages, so unless I want to move to another legacy project (I really don’t) then I’m going to need to catch up quickly.

What else has moved on? A couple of years ago I moved our development team out of the dark ages of Sourcesafe onto TFS. Today TFS (and even Subversion) looks equally antiquated when stacked up against distributed version control systems like Git or Mercurial.

Automated builds are the same – Team Foundation Build simply looks heavy and cumbersome next to Teamcity.

There are bunch of techniques I want to use but can’t easily retrofit to an product – things like test driven development, the use of patterns and good coverage with automated testing. These practices are just standard on most projects now – and I’m not getting the exposure I need to them.

We’ve always build our current software on code generation – our entire data layer is generated by Codesmith. However, this has meant I haven’t had a lot of exposure to the entity framework. It’s hard to imagine building a new .NET project without it.

The support software we use also feels outdated – Sharepoint for storing documents, TopDesk for logging bugs. Of course there are good reasons for our company to use them, but there are so many fantastic (and free) alternatives out there, it’s hard not to get a little bit frustrated.

Basically there are simply too many areas I feel I’m behind in. The good news is that as I work remotely 100% of the time, I have plenty of extra hours (that most people have to waste on things like commiting) to try and rectify the problem. During the last few weeks I’ve been planning out a project that will give me a good chance to get stuck into the latest stuff, and I might even end up developing something useful whilst I’m at it. At the very least I’m hoping the exposure to new things will make me a better developer for my current company and a more marketable developer when the time comes to leave.