July 7, 2009

...Learn TDD with Codemanship

Screen Captures Hold Key To Raising Your Game

I've been experimenting with techniques to help us assess how effectively we apply good habits, and one technique in particular seems to be bearing early and very promising fruit.

Inspired by the example being set by Antony Marcano and Andy Palmer's pairwith.us project, I've been using screen captures to assess how well developers - myself included - apply basic Test-driven Development practices on short coding exercises.

Here's how we've been doing it:

Agree a set of no more than a dozen good TDD habits. These must be simple and enforceable (i.e., it is relatively easy to know when you're not doing them). They could be things like:

* Write the test assertion first and work backwards

* Make sure the test fails for the right reason(s) before you try to pass it

* Don't refactor when there are failing tests

* Refactor out any duplicate code after passing each test

And so on.

Your list of good habits should roughly represent what you (and your peers, if you're doing this in groups) believe is "good basic test-driven development".

What we want to know is, given a sufficiently representative amount of code to produce, how often do you break these good habits? How often do you catch yourself doing little refactorings when you should be just trying to pass a failing test? How often do you leave duplicate code after passing a test? How often do you forget to check that the test actually fails for the reasons you would want or expect it to?

The answer, if my own experience is anything to go by, is more often than you think.

Pick a simple coding problem. Here's a good sample one: write some code that will generate the Fibonacci Sequence of a specified length (e.g., when the length specified is 10, it must generate {0, 1, 1, 2, 3, 5, 8, 13, 21, 34}), where the minimum length allowed is 8 and the maximum length is 50.

That takes most programmers about 30-60 minutes to do using TDD. Using a screen capture tool like Camtasia or CamStudio, record yourself doing this exercise. If you're a fan of the pomodoro style of working, then you can break it into 25 minute recording blocks. Give yourself an hour (or two 25 min blocks) to complete the exercise.

When you've finished, take a break to help refresh your mind and then sit down with a pencil and a piece of paper on which you've listed all the good TDD habits you wish to assess yourself on. Watch the screen recordings back. Watch them very carefully indeed.

Every time you catch yourself breaking one of the habits, put a big X against that habit, and note the time at which you spotted it in the recording and note briefly what you caught yourself doing (or not doing, as the case may be).

Your aim should be to get less than 3 crosses in any hour of programming. It's 3 strikes and you're out, basically. I like to follow the "shoplifter rule". Wait until they have tried to leave the store before apprehending them. If the programmer does a refactoring and doesn't immediately run the tests afterwards, wait until they move on (e.g., to another test) before giving them an X.

If you're doing this in a peer group, then you can asses each other's screen recordings. And you can also vary the exercises and increase the length or the number of hours to make it even more of a challenge. A peer group in one of my clients will be doing 3 hours - in one of which they'll program in pairs and assess each other in pairs, and BOTH programmers get a X each if the pair slips up, meaning that the navigator really has to stop the driver from making mistakes.

Doing assessments is also great practice for pair programming, especially if the screen recording is captured without any audio. With just video, assessors have only the code to go on, which is a bit like a pair programming situation without talking or any other kind of communication. The driver must say what they have to say through the medium of code, making it clear enough that the assessor can understand what it is they're trying to do, and the assessor must concentrate and follow the rhythm of the TDD process so they can clearly see when they are at red light, green light or should be refactoring.

It might even be possible to do a kind of mutation testing by showing assessors a screen recording in which a variety of deliberate small mistakes are made to see how many they pick up on. You have to watch the code like a hawk, believe me!

As with all of these things, there's a bit more to it than I'm able to explain here. In the true spirit of software craftsmanship, you really have to see it to understand it. And you have to do it to really understand it.

The early results have been very exciting, though. It's becoming clear to me that this requires a level of concentration and focus on good practice that is head and shoulders above certainly what I thought was "rigorous" this time two years ago. And the results also strongly suggest that knowledge and cramming don't help. It's all about the habits. If you're not in the habit of doing these things, then at some point you'll slip up.

Which is why it certainly looks as though you need months of regular, focused practice - a few hours a week - to reach a point where you will be able to do 2-3 or more hours of solid TDD to the kind of standard this exercise demands.

It's all about increasing self-awareness. By examining closely what we do and how we do it, we tend to notice all sorts of little (and sometimes big) areas that need improving that might otherwise have gone unnoticed. It's a bit like practicing in front of a mirror for dancers. To do things right, they really need to get a clear view of themselves doing it.

The groups I'm working with now will soon be graduating on to "basic" refactoring - though, as I look more and more at what they'll be doing, they'll still be taking refactoring to a level very few people have mastered. Exciting times!

Posted 11 years, 10 months ago on July 7, 2009