The long way through Software Craftsmanship

Mob programming String calculator kata

Mar 3, 2015 - 3 minute read - Comments - mob-programmingtrainingtddkatastring-calculatorpair-programming

Last Friday we did a kata1 using a projector the string calculator 2 using pair programming, TDD and some mob-programming for the last refactoring.

We used a projector (beamer) so everyone could see it. I tried to take really small baby steps but the adding part was done in ~6 cycles3

We’ve all learnt about shotcuts, live user templates for the IDE 4, TDD methodology, other ways of tackling the problem, how to refactor as a group, clean code, etc

These sessions are necessary to share some knowledge among the teammates and have another chance of doing code review, releasing some pressure from daily practices or bad abstractions / designs (that will be taken care of in the future)

We’ve had such a great time, learning together, that would be a candidate for a weekly interaction.

Mob programming is such an eye opening practice. It forces you to reconsider your previous dogma and to understand the others' positions. Wikipedia reads “early use of phrase […] was made in ‘Extreme Programming Perspectives’” but this practice is practiced by some, such as Carlos BlĂ©, Sandro Mancuso among others; also at the Software Craftsmanship Barcelona 2013 and 2014 and the SoCra Canaries 2015

One goal

Our goal for this session was to practice TDD and baby steps, so the team can improve its ability on these skills.

In any case, my objective for the katas (or deliberate practice) is not to get there as fast as we can but to improve our automated routines. This can affect our daily performance, as it becomes natural. It is not about the getting to the destination but enjoying the path along the way. In this manner, you are not so hurried up about a slow train but enjoy the views across the window.

It was good that QA people in the team came to the session. He even participated with some tips / implementations during the refactors. Always fruitful to discuss (and learn) mixed skills (QA / dev) from the other side of the wall

Conclusion

I still haven’t mastered the recipe (algorithm) for knowing when it is a scaffold and when it’s time to refactor using “replace algorithm”. For know, I just use the three (3) rule and a bit of gut feeling on the side. The bad thing is that this can not be easily taught to someone else. Just learnt by osmosis and practice.


  1. matching none of the styles explained in here ↩︎

  2. This is a very good beginner’s kata, created by Roy Osherove. Can be found here ↩︎

  3. One piece of feedback I received is that I talk too much while coding, as these 6 cycles took us about 45 minutes, total ↩︎

  4. There are some for IntelliJ IDEA, Eclipse too ↩︎

The purple wire Kata: Mars Rover in Clojure