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!

Over the past year, it has been very interesting to see the increasing number of articles regarding the impact of the global recession on IT. Most of these have focused on how to make yourself recession proof, or what to do with the increased downtime between contracts. One problem that does not seem to appear however, is the lack of good candidates when hiring during this time.

Over the past six months the IT job market seems have all but disappeared (in some regions). Projects have been postponed, contracts have dried up within a hundred mile radius and the number of advertised permanent roles has drastically reduced. This isn’t really a surprise given the current economic climate, but for companies who are actually still looking to hire, the problem seems strangely just as familiar.

Many of the candidates currently looking for work simply do not have the skills required and the good developers seem to be holding on tight and riding out the recession. The current raft of resumes are frequently from contract developers, most of these developers are quite honest about their reason for seeking a permanent role, they simply can not find contract work. These developers aren’t typically looking for a permanent role in the longer term however, so should the market conditions improve, hiring a new developer might be a problem all over again.

Joel Spolsky said that the “best people in every field, are quite simply never on the market” and during a recession that seems even more true. With the recession forecast to continue well into 2009, it looks like the good developers are going to stay in their current role and hiring will continue to be a problem. Which leaves the question, the right developer, or the developer right now?