I recently blogged and Tweeted this idea for Cincinnati Clean Coders.  It came out of some work I’m doing with a team that was struggling with TDD adoption and steps we are taking to resolve the underlying causes.

This team had been trying really hard for about 2 sprints, and to a lesser degree in sprints prior, to add TDD to their Definition of Done.  During the second retrospective the team made it quite clear there were roadblocks.  We spent quite a bit of time during that retrospective trying to diagnose and come up with a root cause.

The conclusion was that complicated setup in the tests was the blame.  This isn’t uncommon and is certainly a signal that the underlying system under test is doing too much.  What the team decided was that maybe it needed to focus on patterns for small, flexible, clean code.  So the team came up with…

The Clean Code Plan

At the beginning of each week team members each choose a design pattern, development practice, or tool to learn and practice.  At the end of that week each team member would lead a session with the team.  The general agenda of each session would be:

  • Define and Describe the Pattern, Practice, or Tool.  Bring in others thoughts, comments, and interpretations that you’ve found.
  • Demonstrate the pattern in action.  Since we are working on a project the team decided it was best that this *not* be done in the context of that project, but instead be done with a different background.  We wanted to get out of of the confines of the project and clear away any baggage or pressure.  We had one demonstration that was done in alternative languages to the project language which received kudos.
  • Discuss ways that this could be applied to problems in the past or problems that are foreseen.  This part was hard, but I think will be the most fruitful as we move forward.

Fortunately for this team it can take a few hours (3-5) to do something of this nature.  A public group, not so much.  At least not regularly.

So here are my initial thoughts on a more condensed format.  Post your thoughts, ‘cause I’m all ears.  Maybe I’m being too structured here, but that’s my nature.

Duration: 1hour and half: Two 30 minute sessions on two patterns, practices, or tools.

Follow the same agenda of:

  • Define and Describe the Pattern, practice or tool.
  • Demonstrate the pattern, practice or tool.  Must be done in at least two languages or platforms.  I think this is key to getting people outside their comfort zone.
  • Discuss ways to apply in past or upcoming problems.  This is a bit harder, because we don’t have a common project context around our discussions, but I think it’s important to keep this from becoming a rotation of talking heads.  It would hopefully remove some of the intimidation factor of speaking as well.

So what do you think?  Could it work?  We have an industry problem with quality practices, but no plan of attack.  I’m not saying this is one, but maybe it can help.