Build breaks are a big deal

I’ve explained build breaks before and why they are big deal.

Last night about 10:40 the guy across the hall submitted a code change for review. About 11:35 someone else replied saying it looked good. At 11:49 the guy across the hall checked it in.

This morning I saw the request for a code review and took a look at it and thought, “Hmmm…. just one line was changed. I’ll look at the bug report to make sure this is the right thing to do but it almost for certain should be fine as long as it passes the buddy build.” Then I saw that he had already checked it in–without any mention of a buddy build. Hmmm… Okaaaaay.

Then I saw the email about the build being broken this morning. Then I saw the email about a new bug assigned to the guy across the hall. About 30 minutes ago another other guy showed up with a very large baseball bat* in the hall. I started laughing and went out to watch more closely. I stopped laughing and left when the thumping started. It wasn’t going to be pretty.

I came back after a few minutes and the guy with the baseball bat was gone and I examined the guy across the hall for bruises. There were none showing so I’m assuming his clothes cover them all.

They take their coding processes seriously around here.


*Made of hollow plastic.

2 thoughts on “Build breaks are a big deal

  1. Wow, that’s weak. On our team, breaking the build is punished by feeding the offender to alligators. Of course, since it is such a small team, it doesn’t happen that often.

  2. That’s part of the reason I screamed and yelled for continuous integration and unit tests. We use Cruise Control and nUnit because our management is too cheap to buy Team Anything.

    And we can’t feed anyone to the alligators because most developers aren’t healthy for them and, well, there’s simply not enough of us left to get the job done anyway.

    However, I am paying attention to the fail reports and sending images from here to the offender.

Comments are closed.