<Build failure alarm sounds>
Tim: Sorry guys, that was me!
<A few minutes pass>
Tim: Build's fixed
Steve, Bob (in unison): Thanks Tim!
Now lets examine the behavior of an unhealthy 3 person development team:
Bob: I just did an update and now the build is failing. Anyone know why?
<silence>
Bob: Looks like Tim was the last to commit, does anyone know where he is?
Steve: I think he's in a meeting.
Bob: I guess I'm blocked then (heads to digg.com).
If Bob wanted to get around his block, he could fix the build himself and check in the change. Hopefully, he understands enough about what's going on to really fix it. And an email to Tim to let him know what happened would probably be a good idea as well.
Another option, rarely exercised, is to revert Tim's change to fix the build, and then email the team to let them know what happened. Really, it's nothing personal. Tim just make a simple mistake, he checked in when he wouldn't have enough time to check the build before going to his meeting. Now Bob (and the rest of the team) is stuck. If the fix isn't obvious, or will take a long time, the solution is simple: Just revert the commit.
Tim can recover his changes from source control when he gets back from his meeting and try again. If you can't (or don't) take responsibility for a broken build, and let everyone know that you're working on it, you should expect your commit could be reverted. Again, it's nothing personal...it's just the best thing for the team.
I think there's a sort of stigma associated with source control reverts. People think of it as destroying someone else's work. Sometimes this is hard, because often the thing that's breaking the build is a minor problem, and it's a mistake that we all make. But just as we've learned that refactoring isn't wasteful because it allows us to evolve our design, understand that reverting a commit isn't wasteful because it unblocks the team. And the changes don't go away...they're still in source control and easy for the original committer to recover. My suggestion is to keep this technique in your toolbox, and don't be afraid to use it. You should never be blocked due to a failing build.
Comments