CI Punishment

Sunday February 4thFunny, Software Development Category

For a development to succeed in its use of a continuous integration process there must be a sufficiently hefty deterrent to prevent people from breaking the build. If you break the build, you should feel some form of retribution to aid in stopping you from doing it again.

Plip’s recently posted a suggestion for this very issue. I think it’s a fantastic idea! Make sure you print it and stick it up in your office!

3 Comments

  1. Jason Yip
    February 4, 2007

    I used to think this but now I see this an anti-pattern. I really want people to care about the build because they realise the impact it has on the team, not because they want to avoid punishment. I’ve also encountered teams where breaking the build was “your problem”, not “our problem” and I suspect individual blaming contributes to this culture.

  2. OJ
    February 4, 2007

    Hello Jason! Thanks for your comment. My initial post was a little tongue in cheek ;) But I think your comment highlights a very important issue: finger pointing.

    The affect of finger pointing I think is varied depending on the team and the individuals within it. I’ve been fortunate enough to be involved in teams which are happy to have a laugh at the expense of each other when the build is broken - but we all took a broken build seriously. When the build broke, we’d have a quick laugh, dish out the ‘beret of shame’ to whoever broke it, and then we’d all work to get the build working again. I had a great deal of fun, and did my fair share of wairing that damned hat :) What really worked for our team was that the broken build wasn’t something that resulted in the culprit being flamed, grilled and served up to management. We all knew that broken builds are part of the job. As long as we focus on making sure that the build is fixed as soon as possible then the little jokes such as doughnuts are hats are just to lighten the atmosphere.

    I know where you’re coming from with regards to teams which have a “your problem” mentality, and needless to say the team was extremely inefficient. When the build breaks, it is the responsibility of the team as a whole to fix it. Sure, if it’s broken then the person/people who were involved with the last check-in should be taking charge, but that doesn’t mean that the rest of the team should be sitting idle.

    As soon as teams realise that the build is the team’s responsibility and not just that of the person who’s making the changes, then this whole issue would go away.

    Thanks again for your comment :) It’s good to see someone else out there who has a good attitude with regards to broken builds!

  3. Paul Eastabrook
    February 4, 2007

    Hey dude. Interesting post. Glad you were only tougue in cheek, was going to have a rant then ;-) I would have to say I agree with the outcome of the comments. You even prompted me to post a follow to a previous CI piece I did on my blog.

    Chrs

    P.

Leave a comment

Size

Colors