What’s Not To Like About This Code?

Many teams struggle with evolutionary design and collective code ownership. They have arguments about working standards, code reviews turn antagonistic, and pull requests are either rubber-stamped or sit there for days because nobody thinks they have the right to criticize someone else’s code. How can they get past this chaos towards sharing responsibility for guiding the design to evolve?

“What’s Not To Like About This Code?” is a serious game for teams tired of wasting energy arguing about design decisions. After playing this game a few times, code reviews run more effectively, pull requests are easier to merge with confidence, and the group finds it easier to trust everyone to make significant design decisions. Lead programmers and architects especially appreciate the chance to spend less time monitoring what the team does from day to day and more time focusing on the real value they can provide.

How It Works

How can we organize this game for ourselves?
  • It usually takes 1 hour to play the game, including debriefing time.
  • Propose some code to work with. For your first session, consider using code written outside the group. (If someone in the group volunteers their code, then let them!)
  • Display the code for everyone to see (projector or screen sharing).
  • Facilitator repeatedly asks, “What’s not to like about this code?”
  • Participants try to answer the question. Often they describe how they would improve the code.
  • Facilitator asks the participant to clarify what problem they see in the code, rather than how they would improve it.
  • Participants sometimes debate whether the “problem” is indeed a problem. Facilitator guides the discussion, focusing it on the problems they observe, rather than on how they would fix those problems.
  • Repeat until time is up or the team has had enough.
  • Facilitator asks the group what they’ve learned from the game.

Although the team will raise a variety of issues with the code, this does not become a “to do” list for the team. Some groups feel energized and choose to address some of the issues that they’ve raised, but this game is not intended to add more tasks to what is often already an overburdened backlog. After the session ends, I invite you—and even encourage you—to throw away the list of problems they raised. They’ll raise different ones during the next game.

We play this game in order to help the group converge to a shared standard of work. This changes their design decision-making process over time. They don’t need to refactor everything today and they almost certainly shouldn’t try.

This game works well when the group plays it periodically, say every 2-4 weeks. As long as they have interesting discussions, they’ll want to play again. As they gain more trust, they’ll use the sessions as a way to review their own code. Over time, the team will choose to play less often, but as people leave and join the team, it helps to play the game more often.

Facilitation Services

Although you can run these sessions yourselves, you might prefer my help as facilitator. You can book individual sessions or enlist my help to become an effective facilitator within your organization.

“See One, Do One, Teach One” Package

If you’d like to build internal facilitation skills for this session, then book a 3-session package in which we follow the “see one, do one, teach one” approach.

Invite me to participate in future sessions if you feel you need help, such as a sudden significant change in the makeup of the team.

Booking

Click here to see the current prices, check my schedule, and book your session. Relevant sales taxes will be added at the time of purchase.