February 29, 2004
I was asked this last Friday to bring my Broken Trophy to work. The Broken Trophy has been very effective at improving the productivity of the development team in the past. If you work on a project with a team of developers, this is a must-have item.
I am currently working on a project of 12 developers. Each new development cycle typically translates into the code base changing quite rapidly from day to day, or even hour by hour at times. This usually (and should) diminish as the development cycle progresses. Of course, we often need to get the latest version of the code base to continue developing or unit testing our code. Nothing can be more frustrating when you’re coding away, or "in the groove" as I say, and you get the latest code base only to realize your project now fails to compile. Usually somebody failed to completely check in their code, or their code simply does not compile! This can be very frustrating, especially during tight development time frame – is there any other kind.
Yes, we have all been in this situation, and dare we admit we have even been the one causing this problem for others. No developer wants to be at either end of breaking the build. For this, I suggest to you the Broken Trophy. The broken trophy is exactly what it sounds like – the most hideous, obnoxious, large broken trophy you can find. Again, the larger, the better. This should not be easy to hide or tuck away in a corner.
I found this to be the most effective way of reducing the frequency at which developers break the build for others. Of course, nobody wants this trophy, and you will find some developers resistant to this idea. However, I have experienced that even those who are opposed to the Broken Trophy soon ease into accepting it once they begin to reap the benefits of its presents.
The Broken Trophy does wonders in many ways, all of which are often what you or your teammates either want to do or are doing in less productive ways, recognize it, vent it, and forget it. I have seen this bring a team together. After all, we are all human and we will make mistakes. The idea is to reduce the frequency of these mistakes that hinder the productivity of others. Everyone will eventually get the trophy. It may take a little longer for some than others, but I have always seen it even out in the end. When the trophy is awarded, we usually have a quick announcement and chuckle that lasts about 30 seconds. Nothing more.
Rules for winning the Broken Trophy:
- The code in the source control database does not successfully compile. The trophy goes to the person who broke the build by checking in code preventing the code from compiling successfully.
- The last person to win the Broken Trophy retains possession until the next person earns it. This may be a matter of hours or minutes; or it may be a matter of days or weeks.
- Falsely accusing someone of breaking the build. They may announce they think the build is broken, but not absolutely place ownership on someone. Doing so will earn the false accuser the trophy, if in fact the build is not broken. This has its benefits as you will see below.
Here are things that do not win the Broken Trophy:
- The code does not have to function correctly or even function at all, as long as it compiles. This may sound odd, but functional or bug-free code has nothing to do with this award. Allowing the code to compile, allows other developers to continue developing and testing their code. That is what matters – productivity.
- If someone is in the middle of checking code in to the source control management database (SC).
There may be situations where there is a disagreement as to whether someone has earned the trophy or not. The rules above are clear and will usually determine the answer. If not, a simple majority vote will solve the problem. However, this has rarely been needed. If you lose the vote and are awarded the trophy, suck it up. Your team will respect you for being an equal team member.
Here is a list of the few outcomes you will get:
- The team will find it easier to laugh about the problem instead of getting frustrated.
- The team gets satisfaction in knowing the problem is being recognized. This alone will begin to reduce the frequency of build-busting mistakes. Your team will also become more aware of the lazy mistakes that have earned them (or others) the trophy, and they will be more intent on not making them again.
- The team gets a chance to vent about it. However, the venting is normally not an issue since the presentation of the trophy says it all. There is rarely any need or desire to discuss it any more. Point made, venting done!
- The team can forget about the issue. Although, jokes will continue at the recipients expense, they will soon subside once the trophy is awarded. This is especially true as the trophy makes its way around the team. The problem has been addressed!
- Usually, the root cause of the broken build is researched and resolved before the trophy is even awarded. This causes the team to focus on solving the problem first. This is a beautiful outcome. Remember, false broken build accusations can win the trophy as well. Therefore, the whistle blower soon becomes very diligent in determining the problem before “officially“ sounding the Broken Trophy alarm.
- After the trophy has been awarded to a few people, it will become easier to award and easier to receive, and the team will soon begin to recognize the reduction in build errors. The confidence of the code in your SC database will begin to improve.
I have seen this work very well. In fact, it has always work well. The important point is to remember that this is all in good fun and good productivity for the entire team. Some may see this as being controversial or a public fogging. I have never seen this be the case. The first person to win the trophy is usually the hardest to award – and receive. When presenting the trophy the first time be sure to remind everyone of this. As long as everyone focuses on the lighter side, your entire team will win.
