As developers, making mistakes is an inevitable part of our work. While mistakes can serve as learning opportunities, if overlooked and not acted upon, they could turn into bad habits, which would be detrimental to the team’s progress and the product’s success. Dealing with mistakes that developers make is a sensitive matter. Software development can be stressful, so any method chosen to deal with mistakes should not add to this stress, but rather encourage reflection and promote actions that will prevent repeating said mistakes in the future.

In general, the blame for a problem should not be the burden of one person, but the shared responsibility of the development team. That said, sometimes it does make sense to point fingers, though it doesn’t necessarily need to be in the form of admonition. To deal with professional development and learning from mistakes, there are light-hearted methods teams employ. Here are some examples:

• Hat of Shame: Developers at a company that shall remain unnamed, must wear a funny hat when they introduce a bug to the live system, and would have to keep it on until the problem is resolved.
• Mistake Bank: Another idea is to chip in to a shared company- or team-wide fund whenever you make a mistake that affects other team members. This fund can later be used to throw a party or buy something for the entire team.

At Active Agent, we found that the so called ‘ice cream rules’ do well at balancing the precariously perched scale that is the developer’s ego and the well-being of their team and the product.

Merged a branch with failing tests into master? You’re buying ice cream for the team.

Unintended merge commit? That’s ice cream.

Committed debug code to the production repository? Yup.

Shot a Nerf gun in the office? Wait, what?

Buying ice cream for the team seems to be just the right of amount of punishment for developers to reflect on their mistakes, without feeling too bad about themselves. No one wants to be an ice cream machine (it has happened…) but making your team happy with ice cream once every couple of months is a bearable punishment. In fact, ice cream rules have been well received by newcomers and old developers alike. So well received that, over time, the ruleset has been expanded and revised to a daunting scope.

While this form of punishment worked well for a while, it was not free of pitfalls. The ever growing rule-set was one of them. The number of rules was small at first, but it grew as team members found more practices and behaviors that hindered their performance. At its peak, there were 17 documented actions that would result in ice cream, along with numerous additional rules and sub-clauses that were only delivered verbally. We even had an official ice cream rule guarding against blinking commit messages. Soon enough, whether a developer committed an ice cream worthy violation or not was the most debated topic at the office. Even the tiniest mistakes prompted team members to demand ice cream, citing existing rules and proposing new ones, all to get a taste of that free, sweet, guilt-laden ice cream.

At this point, several members of the team, presumably the ones that were on a diet or spending their monthly salary on ice cream at the supermarket downstairs, started expressing their dissatisfaction. Discussions about ice cream were taking up more time than debates about the software they were developing. We’d not be surprised if developers took late night law classes just to win arguments that would get them more ice cream. A good thing had turned bad, we had created a monster. But did that mean it should abolished altogether?

As it stands now, we are governed by a single ice cream rule. Here it is, taken word for word from our developer guidelines:

Producing impediments to other team members may lead to ice cream.