Code Kata Constraints

I’ve accumulated a number of great constraints over the moderate time I’ve been involved with katas.  With Cincy Clean Coders and Dayton Clean Coders new constraints keep coming both creative participants and crazy things I pull from the morass between my ears.  I can’t imagine this will stop for reasons I’ve already mentioned.

To help me keep track of them and to help others I’m going to catalog them here.

  • Methods no more than 3 lines
  • No mouse
  • No moving cursor more than 2 lines with the arrow keys
  • Test Method names at least 40
  • All methods/properties names at least 30 characters
  • No Classes
  • No Mutable State
  • No Exposed State
  • 3 Refactorings after each passing test
  • No If, Else, Switch Statements
  • TDD as if you mean it
  • No Frameworks
  • No IDE

Replace any number with your preference

If you have ideas for others, put them in the comments and I’ll update the list.

Expand Your Normal

I went for beers with a couple of coworkers today and a question came up that I get a lot.  What’s the point of a kata?  That’s an answer for you to come up with for yourself, but I’ll let you in on my secret obsession: I want to expand my normal.


I have an insatiable thirst for new information.  It can be quite frustrating and, at times, debilitating.  The neat thing about new information, is it changes what you consider normal.  Common sense is a bunch of crap.  Using a fork is common sense… until you move to India.  We should all move to India (or vice versa) for a while.

Not to long ago someone described an art course in which many of the lessons included drawing 50 different types of circles or straight lines.  I imagine around 10 or 20 you start struggling a wee bit.  I was reminded of this while reading Zach Holman’s Slide Design for Developers.  He writes:

I took one design class in college. One of the most fascinating assignments they gave us was a study of shape: you get one letter, in one typeface… do something with it. The idea was that the severe limitation forced you to be creative with duplication, rotation, scale, alignment, and whitespace.

Katas give us a silly background story like Triangle Classification, Roman Numerals, or Harry Potter, but those aren’t the point.  The point is not making the next test pass.  In fact, don’t write any tests next time.  They’re getting in your way.  Pick some other area that you feel comfortable in and come up with a constraint outside your Normal so that when you’re done you’ve moved normal a little bit.

Definition of Done Discovery

One of the important aspects of Scrum and the more fundamental concept incremental delivery is building Done software each iteration.  There are a lot of holes in that statement, but that makes sense; Scrum is full of holes… on purpose.  If you want answers rather than a framework built for learning, Agile ain’t for you.

imageHaving a clear, well understood and explicit Definition of Done that everyone, including your product owner and surrounding teams accept is very important to growing quality and capabilities consciously.  Underlying any Definition of Done is the expectation that the useful (for another day) software is ready for consumption by those who asked for it.

As a new team, discovering your initial definition of done can be surprisingly challenging.  Certainly we can come up with things that we want to do and I say go for it!  Only inspection at regular intervals can tell us for sure where we are and what the impact has been.  But there are some things we can do to help make this decision more effectively.  And it doesn’t take long.  30 minutes… maybe.

Circles and Soup

Innovations Games has a fantastic activity with many applications called Circles and Soup (sometimes called The Soup).  I’ve used this to help a pissed off team focus their energy, but it’s also very helpful in creating an initial Definition of Done that is truly attainable.

You should read the full instructions, but suffice it to say the team will categorize those activities both historically done (i.e. architecture review) and potential (i.e. TDD) that must or should be accomplished to deliver into: Things They Control, Things They Influence, or The Soup (things they have no control or influence over).  This is immediately actionable information, but also a roadmap to move items into the teams control.  Share this with your organization and advocates.

A Definition of Done, something that they agree will always be completed before calling a feature or story or product backlog item done, which includes activities outside of the team’s control is risky or foolish.  You should control your own destiny as best as possible.  How can a team ever feel at all confident in their own forecasts otherwise.


In the Professional Scrum Developer course we talk about and spend a few minutes brainstorming attributes that define quality.  We call these ‘ilities’.  Things like maintainability, supportability, reliability, performance-ability.  Ok I made that last one up, but you get the idea.  It’s a big list too. 

Very few people will argue that missing an -ility negatively influences the quality of an application. Which –ilities are most important, though, depends on many factors.  Type of application, type of user, industry, etc.

What I like to do as a facilitator for this activity:

  1. Ask the team to break up in pairs or individuals for 5 minutes.  Write every attribute that affects your impression of any application you’ve ever used on a sticky. 
  2. Then come together, remove duplicates and put them on the wall for another 5 minutes (usually less).  This creates discussion about what people intended or experiences.  Often another -ility or two will be discovered.
  3. Use dot voting or some other form of ranking to figure out which –ilities are most important to this application.
Putting it together

You should now have a good idea of what the team has true ownership of and what is most important to build a great application for the intended customer.

With the results on either side of a whiteboard or giant sticky, choose a few activities which correlate the important –ilities and the activities in the team’s control to determine an actionable, checkbox-able list of things you feel will assure each feature and sprint produces Done software.

Each iteration you have the opportunity to review these artifacts or recreate them to evolve your Definition of Done from good to great.

Cincy Clean Coders – Code You Can Show Your Friends

What would a Monday following an Agile conference be without the announcement of a new group focused on quality practices!


I’m happy to announce that Cincy Clean Coders is really going to happen.  Details can be found at, but suffice it to say the inaugural meeting will be held April 7th at 6pm in the Max Train facilities in Mason, Ohio.

Mark Haskamp was strong armed brave enough to offer to go first with me.  I’ll update the site with the topics for the first meeting soon.

Big Thanks to Ernie Stormann and Parag Joshi who helped push this through.  And a big kudos to the rest of Twitter for being excited about a topic like this.  It says a lot about where our industry wants to be.

Help! You might notice I’m not a designer.  If you want to help, we could use a site design that doesn’t compare to notepad in a browser.  Nothing special, just, you know, some other than black on white text.

Expanding Quality Dev Practices: Clean Coders

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.