Don't Let Donuts Taste Like Defects

Over the course of my engineering career, I have seen and participated in different types of team traditions. Team traditions can help build the identity or brand of a team, which is generally helpful in supporting the overall health of the team. By having a team which has a unique and strong identity, it many times indicates a strong connective bond between the team members. As the lifespan of a team grows over time, traditions can continue to form which further crystalize these unique elements of their identity.

One tradition I have found, which may seem innocent, can have larger negative effects than desired. This tradition is what I will call Defect Donuts. In this short post, I will share the importance of focusing on positive reinforcement within in a team, and avoiding punishment when seeking ways to motivate desired behaviors.

Defect Donuts

The tradition I call Defect Donuts, is a rule that a team may follow when a defect or issue is introduced in their code base. For example, if you check-in code which introduces a defect, the defect will introduce some cost to your team. Your software quits working in some environment, tests begin failing, and maybe a team member has to engage in some investigation to find out your code change introduced the problem. Since you realize your mistake had a negative impact on the team, you feel bad and want to make amends. The tradition of Defect Donuts establishes an expectation that you then bring in donuts the following day to indicate that you are sorry for the issue and recognize the impact.

This tradition reminds the team of the importance of not making mistakes. While no one wakes up in the morning with a plan to make mistakes, this tradition highlights when someone makes a mistake within the development ecosystem of the team. When the mistake is identified, the team then seeks a human for the cause, as that team member is then responsible for brining in donuts. As part of a team, you want the entire team to support a system of producing software. The system becomes the focus of improvement when you encounter issues which have entered into your code. Therefore, while humans compose your system of building software, you don’t seek for a specific human as the cause of the issue, but rather how did the overall system allow it. For example, if a code change that was introduced that could have been caught with static analysis in your build, you would seek to introduce static analysis in your build, versus identifying the single human that didn’t know this and then ask them to bring donuts so they would learn from that mistake.

Reinforcement and Punishment

When you are seeking ways to encourage human behaviors within teams, there are options of using reinforcement or punishment. With reinforcements, there are generally two categories: positive or negative reinforcement. As the names imply, positive reinforcement is when you provide a reward for a desired behavior. Negative reinforcement is when you remove something (like something unpleasant) as a result of desired behavior. Other ways of influencing behaviors, is through punishments. These can be imposed by introducing or removing something when you see an undesirable behavior. In the case of Defect Donuts, you are imposing a punishment for someone to go buy donuts (which might not be that bad of a punishment), and then you also have a slight positive reinforcement to team for getting donuts by identifying a single human identified as a cause of an issue.

From my experience, you generally want to focus on utilizing positive reinforcement for encouraging human behaviors, and seldomly use negative reinforcement or punishments. While they all can be effective to some degree, favoring the use of positive reminders generally have better effectiveness, and can be used more frequently while also staying effective.

Donuts Shouldn’t Taste Like Defects

When I have talked with teams that have had this tradition, you generally find it isn’t imposed often. When it is triggered, it is simply trying to serve as an apology, since they know their change had an undesirable effect on the team. I found it more effective to simply remind people of the good work they are doing with donuts, vs. donuts being triggered from a punishment. Encourage them to find defects, and not hinder on sharing their own mistakes for the cost of some punishment. Furthermore, you don’t have to worry about some negative association being tied to one of the greatest activities that exist, eating donuts. Don’t let donuts taste like defects, but rather the reward for great achievements on your team.