Making the smallest change to make a test pass is not the same thing as making the simplest change

Considering my recent rambling about the power of words I had an almost embarrassing experience at yesterday's dojo. When you look at the existing TDD literature it typically says; write a failing test, make a smallest possible change to make the test pass. When I learned TDD I also learned that being able to make these small steps is the important part because that is what you revert back to when things get difficult but in practice you might skip the simple, almost stupid things. When you're in a flow you don't typically write code you know you'll refactor in two seconds. Let me explain with two examples. Let's use the Bowling Kata as an example. Let's assume you have a test for a gutter game (all zero rolls) where the implementation just returns zero we would have something look like this for the implementation:

    1:  public class Game
   2:  {
   3:      public int Score(int[] rolls)
   4:      {
   5:          return 0;
   6:      }
   7:  }

Adding a test for a all ones, making the smallest possible change to make it pass could look like this:

    1:  public class Game
   2:  {
   3:      public int Score(int[] rolls)
   4:      {
   5:          if (rolls[0] != 0)
   6:              return 20;
   7:          return 0;
   8:      }
   9:  }

However there is another simple thing you can do with a few more key strokes:

 
   1:  public class Game
   2:  {
   3:      public int Score(int[] rolls)
   4:      {
   5:          int score = 0;
   6:          foreach (int roll in rolls)
   7:              score += roll;
   8:          return score;
   9:      }
  10:  }

Either you argue that my first example is simple and stupid and that the second one is better. But then I could say that the coding dojo format is intended to always do the smallest possible changes (baby steps) and the second version implements more than just an all ones game. Actually baby steps is defined as small steps to keep them trivial. The first dojos I attended however kind of enforced smallest change possible and that makes sense in some way because I think it proves that even when being almost stupidly strict you eventually end up being able to refactor into something nice. The down side however is that it is a terrible experience if want the dojo to be a good TDD experience for people learning TDD because all that minimum changes makes your progress really slow.

So let's look at the last version again. Sure it implements more than just a all ones game but that is conceptually the same thing as all twos and so on. Only strikes and spares are really different. Also the last example involves more key strokes but it is still simple since it only solves one dimension of the problem (the other dimensions being spares and strikes) and it is also a simple change that is easy to understand.

And another good thing about focusing on simple changes over small changes is that simple is what you should do all the time while the smallest often is skipped for a larger but simple change. So much in the same way Behavior Driven Development and Example Driven Development better describe what Test Driven Development is all about I think simple change better describes what you're supposed to do. Both in a coding dojo and in real life.