Taking Baby Steps++

It was at our Munich Softwerkskammer Software Craftsmanship Meetup in early 2013 that we first did a “Taking Baby Steps” TDD kata session based on a simple constraint: you have to time-box the phases when you’re in a “red state”, which is indicated by a failing compiler or test. If you can’t make it back to “green” in under two minutes (until your phone timer rings), you have to discard your current changes, revert back to your last green state and try again. Otherwise you’re allowed to commit the green state and continue. The session therefore challenges your ability to split up your steps into much smaller ones than you’re used to.

   by   Seattle Municipal Archives  

Adi Bolboaca developed the constraint during a genuine legacy-refactoring project . At some point taking steps that were too big had cost him two thirds of a day’s work, because he wasn’t able to find the root cause of an error introduced during refactoring. Personally I’ve been in countless situations like that, each time getting quite frustrated over wasting too much time searching for the cause of such errors.

In the past couple of years I’ve stumbled upon different ideas related to “Taking Baby Steps” which I recently used to refine the session format.

Related Approaches

Back in 2011 I attended Kent Beck ’s very educational “Responsive Design ” workshop. While the term is commonly applied in the context of dynamic web-page layouts, Kent uses “Responsive Design” to describe the processual aspect of designing software as opposed to the usual static perspective on software design. It focuses on the dynamics of code changes, not on the code’s structure at one point in time.

For a while when at work, Kent was observing himself making code changes. He found that all these changes could be categorized into very few design-changing patterns or strategies:

1. “Leap”: taking one big step
2. “Parallel”: having one old and one new version running simultaneously, replacing the old usage one at a time and finally removing the old version completely
3. “Stepping stone”: building a small “component” you might need as a building block in the future
4. “Simplification”: implementing a narrow but full-stack vertical part of a bigger feature

Regarding the kata constraint 3. and 4. seem to promise the most value. In the context of TDD, “simplification” typically means slicing a too large acceptance test into many smaller ones. The “component” strategy on the other hand mirrors basically “classicist ” bottom-up TDD. And although the “classicist” Kent Beck doesn’t explicitly mention it, don’t forget that you can also choose to start top-down “mockist” or Outside-In TDD style.

Last year Seb Rose tried to solve the „Diamond Kata“. This kata really suits the „Taking Baby Steps“ constraint because the next acceptance test forces you to implement almost the whole diamond algorithm at once rather early. So it really makes you think hard about how to split up your steps into smaller ones.
Introducing “test recycling”, Seb tackles this challenge by applying a variant of Kent Beck’s “simplification” strategy: instead of starting with a test which forces the whole implementation all at once, you begin with a very simple test that drives only a small part of the implementation. Then you don’t add a new test, but “recycle” the existing one by complexifying it (as well as the implementation) bit by bit. You continue to do this incrementally until you reach the full complexity of the algorithm. Seb’s short example gives a first idea of this process.

Last year was also when Johannes Link came up with “On-Site TDD ”, a variant of Kent’s “component” strategy: as an alternative to making helper methods temporarily public in order to be able to test drive them as “components”, you add assertions into the production method itself. When the partial functionality is implemented, you remove the assertion from the production code like you would with a scaffold when building a house. As some commenters of the post mentioned, if your language offers one, leveraging a REPL can be another way to achieve the same goal. Both approaches provide a very fast feedback loop, but also lose the ephemeral fine-grained “tests” afterwards. Because the functionality is covered by more integrated tests against the public interface, this is acceptable though.

At the SoCraTes conference 2014 we learned about the “Mikado Method ”, which we also tested in a session during one of our last Softwerkskammer Meetups . The approach helps to minimize the step-size during large-scale refactorings on existing code. So far I haven’t deliberately used it for test-driving new code and currently see no applicability for TDD. If you have a suggestion, though, I’d be glad to hear from you.

Refining the session

A couple of weeks ago I came up with an idea to refine the original session format of “Taking Baby Steps” based on the aforementioned approaches and gave it a try at our last Softwerkskammer Meetup , as well as at the DevCampMuc 2015 conference two weeks ago.

First of all I chose the wonderful diamond kata which I appreciate because it can be solved in so many different ways. The special challenge described above combined with the two-minute time box from “Taking Baby Steps” makes this kata a great fit for the session. Besides kata and constraint I introduced the different approaches (Kent’s strategies, “test recycling” and “On-Site TDD”) at the beginning of the session. The goal was to provide the participants with a set of tools making it easier for them to solve the kata under the given constraints.

Session experience & feedback

We had a lot of fun and a great discussion afterwards. The feedback was quite positive and the participants were impressed to find that such small steps are really possible. But there was also room for improvement.

When introducing the approaches you should explicitly mention that they’ll be needed afterwards during kata-solving. In terms of the kata and the constraints it’s very important to explain all the details and ask whether everyone’s fully understood them. Although Adi had emphasized this point, my explanation apparently could have been more thorough; there were still a lot of questions raised. Instead of strictly following the two-minute timer procedure, do focus on explaining the actual goal of minimizing the “time in red”. Some people really got the wrong impression. They interpreted the two-minutes kata constraint as a strict “revert after two minutes” rule to apply in daily development work. Thus they ended up questioning the potential of “Taking Baby Steps” instead of seeing its huge potential.

Being new to their current development environment, or pairing on a machine with a keyboard layout, editor or language that was different from the one they were used to, some attendees were overwhelmed and thus got quite frustrated. So we came to the conclusion that you should scale the length of the time box according to your familiarity with the environment. Two minutes are suitable for a developer familiar with the environment. If you’re not, increase the time appropriately. On the other hand, if you’re making progress and observe that you’re improving, feel free to start pushing further and even decrease the two-minute time box.

Conclusion

In our experience, the combination of the “Taking Baby Steps” constraint with the “Diamond Kata” is a nice fit. Explaining the aforementioned approaches to the workshop participants before the kata makes them get started more quickly and establishing common names for the patterns beforehand helps to improve communication during discussions.

If you’ve missed the session, I’ll facilitate it again at the Agile World Munich Conference on the 30th of June 2015; or just check the slides . And of course, simply try out the session format yourself – I’d be happy to hear about your experiences!