Day: November 2, 2007

Project Quality / The importance of a build server

Whenever anyone asks me: “I did a ‘Get Latest’ and now my code won’t compile”, I always kick of a build in Team Foundation Server.

If the build succeeds, it is an environment issue on your machine. If the build fails then we are going to have a look at what projects are not compiling on the server, and who last touched them.

Jeff Atwood has a great blog entry today about ‘Works on my machine’, which I have heard time and time again. He talks of the importance of a neutral build server, and I couldn’t agree more. It is so easy on long running projects for tacit knowledge to become ingrained. All the old timers say “We need more documentation”.. but nobody ever gets a merit award or pay rise from writing documentation, so it never gets done.

He also linked to a great article on Hacknot, which chronicles a discussion between a new developer on the project and the resident ‘Alpha Geek’.. I have had this experience once in my career, and it is just not pleasant.

I think a lot of senior developers like the feeling of being indispensable.. I mean you are senior for a reason right? It is an ego thing which is probably understandable from people who worked hard to get to their position. Not good for the project however.

Recently my project manager lent me a book called ‘Good to Great’ by Jim Collins. He makes the distinction between a ‘Level 5’ CEO who sets his company up future success and a ‘Level 4’ CEO who is more interested in his own personal success. In fact the ‘Level 4’ CEO is happy when failure ensues after his departure, since it highlights just how indispensable he was.

A lot of projects really focus on the goal of software delivery, and make rewards around meeting this. That makes a good project. Maybe to make a great project, we need to examine the processes that guarantee future success like prescient and relevant documentation, a decent neutral build environment and ownership with accountability for someone to get new team members on board quickly.

Update 04/10/2007:

The ‘project’ mentioned was some time ago in a previous company. I now work for a consultancy where these kinds of problems seem to be solved simply by the demands that we start and finish on a tight schedule.

That is not to say a traditional software house can not run a tight project, but the requirement to get a software engineer on board quickly is probably less because their time is not counted as a ‘cost factor’ as much as in a contracted piece of work would be.