The organisation that I currently work for has two really nice practices. Once a month there is R&R day – research and reading day – come to work and research something that you choose to research. The other is TEK day – a mini internal conference focused on mini presentations and in the afternoon a lab. This is also once a month. Both of these days focus on no client/project work. The agenda is driven completely by the employees.
At the last TEK day I ran a lab on TDD, Pair Programming and Purposeful Practice. The goal was to give everyone an idea about TDD as well as one way to pair – ping-pong pairing – and to experience it doing some standard coding katas.
Here is the lab – TDD Pairing Practice Lab – if you’d like to read the details. It gives a very brief overview of what TDD, pair programming and purposeful practice all are. (Very brief… I did it the night before and I’m not sure it was sufficiently detailed, but there are several links and it gives you a start on the ideas so you can try them out.)
What did I learn?
I may have introduced too many things at once
I wanted to link ping-pong pairing and TDD together as it feels obvious and I’d been doing it with one of my team members. Sadly he was on leave so couldn’t add his perspective at the session. That said, possibly I should have focussed on TDD only first. And then I could possibly have done another lab later in the year on pairing to add that in. Doing too many things at once may have confused the process.
It is not just about the devs
Pairing gave the opportunity for non-devs to pair with devs and get a better feel and understanding as to what TDD and unit testing is. I think it was insightful and helpful to them. It also highlighted that this could be possible in your day-to-day work – exposing the non-devs to what you’re doing and how and increasing the communication flow between team members.
Requirements are hard
I had a typo or two. And it was clear in my mind as to the goal of the simple requirements of FizzBuzz, but many questions were solicited around when things became a combined FizzBuzz instead of just a Buzz or Fizz.
Stress it’s about the TDD and code
Some groups spent a bit of time ensuring the console app worked. The focus for them was meeting the criteria of printing out the numbers when the goal really was the process flow of learning TDD.
FizzBuzz took longer than I expected
We took much of the 2 hours on FizzBuzz. Which was interesting by itself. I expected things to go faster and hence included the more interesting StringCalculator kata.
Question 6 wasn’t very meaningful for FizzBuzz
I threw some food for thought in question 6 – how would you write it more procedural / object oriented / functional / etc but on such a simple problem it might not be as easy to see. In the StringCalculator I think the questions might be more relevant. And of course this had nothing to do with anything related to the core learning objectives of TDD and Pairing.
No one refactored (much)
It is red-green-refactor, but I didn’t see much refactoring towards beautiful code. Perhaps I’m switched into a certain frame of mind at the moment as I’m re-reading Clean Code again. But I suspect I’ll need to do a lab on readability and attempting to be DRY. As well as when to refactor to new classes, etc.
Would anyone try it?
This was very non-committal. But I think everyone had fun and everyone had better clarity on what it all meant. Again – combining pairing with TDD – and asking “would you give it a try?” encountered a lack of enthusiastic response. Maybe if it had just been one concept it would have been more interesting discussion.
One piece of feedback was that the ping-pong cycle was too short. We did discuss a little that most likely it may not be as short in a complicated piece of code and the examples we were using for FizzBuzz definitely weren’t complicated. But there was some concern around that.
Open to the discussion
The best part of course is that I had an open forum to present and everyone enthusiastically gave it a try. That is awesome.
What would I change?
Ask more probing questions in the debrief. Generally plan the debrief more deeply in order to generate more insights from and for the individuals.
– Who refactored their code?
– Who thinks their code is the most beautiful they could achieve?
– Who changed their code while keeping the tests running and refactored in small steps?
– Was it useful pairing with someone? To learn? To understand the requirements?
– What did you learn? What was really interesting? What was frustrating?
Do less, help more
– I spent a little time challenging one group’s implementation of FizzBuzz which resulted in them refactoring. I should have done that more to see who else refactored instead of going from “it works” to “next problem”.
I’m sure there is a lot more – including a bunch of the stuff in the learnings. But overall I’m pleased with having done one more baby step in moving my organisation to at least understand XP practices. While at the same time I continued to experiment and learn more deeply as well.