Pramatr Blog

Whenever I receive an angry email from Hudson, I start to have very mixed feelings. My first emotions are pride and relief that we work with a build that catches problems and allows us to be troubled by them early in our process. My second emotions are torment and disappointment when I drill into the failure and see what has actually broken the build.

Everyone breaks the build, that’s just a fact of life. Anyone who has never broken a build; doesn’t write code, has never committed any code, works on a project without any tests, doesn’t write tests for their code or is just a phenomenal developer the likes of which many of us have never or will never see. The frustrating thing about build failures however, are the ones that are so easy to avoid. The thing that is even more frustrating than these build failures are the reasons given by the developer who caused the failure in the first place;

• It was only a small change
• Another developer had reviewed the code for me
• Someone was harassing me to check the code in
• The build is fixed now isn’t it
• Everyone else breaks the build
• I didn’t have time to run the tests
• I’m not sure what tests I’m supposed to run
• Nobody else runs the tests

The common thread through all of these statements is the lack of ownership and respect for the other developers. If you are checking in code on a regular basis that you don’t have confidence in or haven’t run tests against, what does that really say about your relationship with the other developers. Is this a team or just a bunch of developers that happen to work together?

If you broke the build, you broke the build. There are no excuses, reasons or justifications required. The only thing that needs to be done is the build needs to be fixed; not in a minute, not in an hour, but now. Everyone breaks the build, but everyone must also ensure they fix the build as well. Collective code ownership applies to every part of the project and nobody should be exempt from having to clean up their own mess.

If failing builds are continually a problem, many teams adopt punishments for developers that break the build. In the past I have found most of these punishments to actually be counter productive. Developers are not stupid, if there is a way to get around the punishment or to make it work in their favour they surely will. Things that punish developers can actually ensure that they commit code less frequently, push them away from the other team members or just be down right illegal. I am pretty sure nobody agreed to public humiliation when they signed their employment contracts. The aim is to change developer’s behavior without introducing more negative problems.

The most effective treatment I have found in the past is to make the build failures more of a team game. This used to be managed manually, but recently one of our team found a Hudson plug in called the Continuous Integration Game which takes a very similar approach (and we really thought our approach was original). Team members receive points for successful commits as well as losing points for failing ones (although we actually use different weightings for the points given). This provides real incentive to change habits, there is nothing like a measurable quality to make people sit up and take notice.

At the end of our two week sprint of work, the developer that loses the game buys cookies for the rest of the team. It’s only a small gesture (around £2 for the whole team) but a symbolic one none the less. The team really do like cookies and they sure don’t want to be the developer that has to buy them for everyone else (nobody likes to lose). When the next sprint starts, the game is reset and everyone looks forward to the cookies at the end of the sprint.

This game has actually injected a healthy attitude into the development team with everyone trying to avoid that failing build. Developers still regularly commit code, but the build failures aren’t as frequent as they once were. But should the worst happen and you receive that angry email, don’t forget to remind your team, every time a build fails a fairy dies!

When I first started my software engineering degree, there were plenty of people I met who simply didn’t want to be there. After a few months they’d had enough and moved onto something else, and after a couple of years the classes had halved in size. I’ve actually met a few people in the industry who behave like they don’t want to be here either, but I was hoping they were in the minority. After speaking to a former colleague however, I’ve found that the problem might be much worse than I had thought. The contradiction of the developer who isn’t interested in development.

Let me just start by saying, if you’ve got this far you really aren’t one of the people I’m talking about! Hopefully you’ll see this as a good thing .
Read the rest of this entry »