Day: October 7, 2004

Lessons from a Successful Agile Project Part 4

Anyone that knows me would have expected me to spout on about tools and build issues by this point, and I think its pertinent how important the previous points were to this project that build gets pushed into the fourth chapter, but here it is finally.

Technical Automation

Despite having 10 highly productive developers, and a fairly complex build process, we did not need a full-time ‘Buildmaster’. I think there were a few reasons for this:

– A few of us on the team had had enough build experience over the years that we now had a good feeling of ‘what worked’ on an agile project

– The build environment was under the same common ownership as the source base

– Major build improvements would be driven by specific stories

– Minor build improvements would be treated as refactorings and done at any time

This was beneficial since no one person was ‘stuck’ with the tag of being in charge of the build, and everyone else on the team felt empowered to change anything that was causing them pain.

I should add at this point that if your build / deployment setup isn’t sufficiently automated and easy to troubleshoot, then you probably will need a full time Buildmaster. One of their tasks should be to make themselves redundant by adding such behaviour.

Lesson 6 : Aim to not have a specific Buildmaster. Instead, treat the build system as part of the commonly owned source tree and make sure anyone can add value to its on-going development.

There were many things that worked really well in our build system but I’ll just talk about 2 of them. The first covered the area of build configuration.

I’ve seen many ‘difficult’ build systems where there are a plethora of build config files, build launch scripts, environment variable dependencies, complicated build invocations, etc. All of this is (in my mind) totally unnecessary. On this particular project, there was one property of build configuration that changed between developer workstations and that was the database name to use. Apart from that, everything was the same. So the entire configuration for our development workstation environment of 15 (or so) machines fitted in one page of a properties file which itself was checked into source control.

Now of course we had some clever stuff going on to handle figuring out what specific machine you were using, how to override for Continuous Integration environments, etc., but most of the time developers didn’t have to worry about it.

This setup saved us so many headaches and so much time that I would now always consider it a ‘must-have’ for any future project I work on. I hope to write an article on the exact details at a later date, so keep your eyes peeled.

Lesson 7 : Minimise the complexity of your build configuration system. Keep the entire development environment configuration in one file and store it in Source Control

The final thing I want to mention here is our database automation. We migrated the full database on every build. Go back and read that last sentence and think about it for a moment…. OK, I’ll tell you why I think its great:

– We never hit a data migration problem on release: we migrated all the time, against real data and so any problems were caught early

– We didn’t have an ostricised data team: data migration work formed part of any story that required it and all the developers did it.

– Since we wanted to ‘do it all the time’, the data migration process was highly automated. That meant our DB release process that we gave to the operational DBAs was really-simple, reducing likelihood of errors and getting us in the DBAs’ good books. 🙂

– We could release at any time – we always had enough data migration code written to support the state of the code base.

Technically. we did this with a bunch of NAnt script and command line ‘osql’. Again, it would be too big to document in a blog item but I hope to write it up later.

Lesson 8 : Make data migration part of your regular build. Make developers write data migration code as part of implementing a story that requires it.

The people were right and the leaders were wrong

It was a spring day early last year when I joined a million other people in London alone to show my disagreement with going to war in Iraq. I’m not an actively political kind of guy, but it just seemed fundamentally wrong to be going to war over (at best) tenuous evidence. Robin Cook agreed and resigned, despite being a senior member of the UK’s government and therefore having access to a whole raft of information that the general public could not see.

The justification for war given to the British population was that Saddam Hussain was hording Weapons of Mass Destruction which he could readily deploy against our green and pleasant land with a mere flick of the wrist.

As a new report today shows, we were lied to.

The american people were told that they were going to war to stop Al-Qaeda launching any more attacks on their country. But now Donald Rumsfeld says he knew of no “strong, hard evidence” linking Iraq with the terrorist organisation.

But does all this really matter? The war is over and there is nothing we can do? I would argue that more than 10,000 civilian deaths and 1,000 military deaths (and let alone the economic cost) shout for justice.

I voted Labour, and so for Tony Blair, at the previous 2 British General Elections. I will not vote for someone who treats war so casually again and so will not vote Labour until Tony Blair resigns. I challenge anyone who believes in justice and truth to think similarly at the upcoming US and UK elections.