The "It Works on my Machine" Award
Sunday, June 15, 2008 – 8:06 AM
An imaginary conversation between you and another developer on your team, whom we’ll call Fred.
You: Hey, the build is broken!
Fred: No it’s not.
You: It is. The CI server is red and the log says that one of the projects is missing a file.
Fred: It’s red?
You: Yes… You did the last check in.
Fred: Well it works on my machine
Fred just won the “It works on my machine” award for the day/week. This isn’t new, Jeff Atwood blogged on this last year and you can even get mugs and T-shirts for repeat offenders. Ed Jez pointed me at it today and I liked the idea so much I wanted to write about it.
Fred’s an experienced developer and is just stating a fact. He’s going to have a slightly harder time fixing the issue but is already on the case. I have seen less skilled people shrug and go back to whatever they were doing as it’s clearly not their problem. Finger pointing and randomization usually ensues.
The only machine that really counts is the CI server. If it’s build is broken someone should be fixing it. Typically on my projects I like this to be the person who’s check in caused the problem but sometimes that isn’t possible and the person who finds it has to step up and deal with the issue. The key is getting the issue fixed as quickly as possible.
It works on my machine can be a smell. I could be a sign of people doing large check ins (and forgetting to add all the files), when maybe you could break them down into smaller ones. This isn’t always possible and you’ll still get build breaks this way. It can also be a function of a large project with lots of dependencies and a hard to reproduce build environment.
A common build script can make problems like this easier to fix. Being able to run the build script used by the CI server on a development box really helps. It doesn’t stop the problem but it does allow for faster fixes as it removes one variable from the problem space, the build script.
Occasional build breaks aren’t bad. They can and do happen. The whole idea behind a CI server is to lower the cost of check in but still be really sure that your product is building and passing tests. What’s important is that they get fixed as fast as possible.
If this is an endemic problem on your team then maybe it’s time to start handing out awards.
Welcome to my blog on software development and probably a whole lot more.
5 Responses to “The "It Works on my Machine" Award”
Well, this is why we follow a strict “4-eyes-policy”.
– in case someone checks “something” in, he firstly has to check if his changes do collide with other changes (manually), or better: has to update his project an recompile it.
– in case (after checkin) a build-tool tells us that something does not work, the person who checked in is named by the tool and he has to resolve the dependencies.
– in case someone checks “something” in, some other programmer has to update the complete project on his computer and recompile it to see it working.
Works pretty fine for us : )
Just my 0,02$, Georgi
By Georgi on Jun 15, 2008
The machine that counts should be the CI, and it is a smell if it doesn’t. Sometimes it takes extra work. For example, for the Mobile Client Software Factory project at p&p, this is what the build lab had in order to deploy tests to physical mobile device and run them there (as the emulator can behave differently). We made it ‘the machine that counts’ by, well, putting a phone in the build rack:
http://www.flickr.com/photos/edjez/225719862/in/set-72157594328732851/
By Eduardo Jezierski on Jun 21, 2008
Georgi,
We use the four eyes polity too, most agile teams do. All code is either pair programmed or reviewed prior to check in. This becomes more challenging when the team is distributed across time zones.
We don’t have a second developer build the changes but rely on the CI serrver to do this. CI has the additional advantage or automating some of the work and making it less prone to human error.
I have a paper (see the publications section) which outlines the potential savings of an automated CI based approach over a completely manual one.
Ade
By Ade Miller on Aug 12, 2009