When I walked into work and saw a red cane hanging on my friend Ian's cube I knew that he committed some (probably untested) code to the repository the night before that caused the automated nightly build (or unit tests) to fail. In other words, Ian broke the build. This was one of the ways my old software team tried to keep things fresh and hold everyone on the team accountable for silly mistakes.
If you were the one that broke the build, not only did you become the new proud owner of the cane of shame, but, you were also responsible for delivering all of the release disks to the SCM lab and additionally tasked with building and delivering integration disks to the test engineers. This punishment typically went on for about a month (until the responsibilities --not the cane-- got transferred to a random group member) or until the next poor sucker broke the build.
This method seemed to work on the surface, at least, I know it did for me. I never committed anything to the repository until I updated one of my clean projects, built it, and ran all of the unit tests. Easy, right? Why doesn't everyone on the team do this? Why can't they just be more careful?
The problem with this approach is it becomes increasingly easy to get into the blame game. If developers are breaking the build on any kind of regular basis maybe the problem isn't with the developers in the first place. Maybe there is a problem with the development environment.
If a team member is swamped with work and checks in their code carelessly, this is a scheduling issue. Or, if a developer is working on too many different things at once and forgets to check in some of his files, this is a work allocating issue. What if a programmer changes some code that breaks another programmers code? Isn't that his fault? Maybe, but more than likely the problem could be a lack of unit tests. See the trend? All of these are problems that can lead to broken builds, buggy code, and burned out developers. But, all of these problems are also solvable.
Instead of asking employees to be more careful or forcing them to take another training class on how to use that crappy in-house bug tracking system your company built. Maybe it's time to be a little more aggressive about finding the actual root of the problem and work on solving that.
Being proactive about problems that arise and trying to solve the root of the problem itself is vital to any software team. After all, it's all fun and games to harass your team members by hanging a red cane on their cube wall when they screw up. But, what happens when someone in upper management (who probably doesn't understand development) realizes that they can start attaching numbers and running reports that provide details for each individual developer and how many errors they've made over the course of the year? This is the nightmare scenario that can at best lead to a CYA environment and at worst create a culture where team members stab each other in the back to avoid blame.
Instead of blaming the person for screwing something up, we need to start blaming the problem. When an error occurs, the best approach is to find the root of the error and try to fix it. The key here is to do everything you can to reduce the probability of making mistakes.
Maybe it's time to write unit tests for that legacy code, or, build that script to automate some tedious task that everyone on your team has to do every week. Step up, be the hero, and solve the problem. Trust me, you'll be better off in the long run.
Think about it.