I was reading the Patricia Benner book, and came across a section (which, annoyingly, I now can’t find) where it argued that for training people at the higher skill levels it is more appropriate to present them with details of real cases than simple examples concocted just for training purposes - gives them more to get their teeth into, so to speak.
I’m reminded of a situation in a large company I worked for a few years ago. It had been decided that all developers needed training in object orientation. There was a great deal of experience and expertise in the office I was in, but nonetheless we all went along to a week of training sessions.
The trainer turned out to be a bit of an evangelist (sing hallelujah) and considered it his duty to give us the good news of Test Driven Development. He was given quite a hard time, especially by a couple of the more experienced developers. This, to be fair, he took mostly in good humour; but I think he thought he was dealing with stubborn old-timers who were dismissing what he was saying out-of-hand because they just didn’t get what he was saying. (I don’t think he cottoned on to the fact that they were giving him the third degree precisely because they were taking him seriously.)
In order to win people over, he did an extra session where we went through the Bowling Score exercise. (Using TDD to write a program that scores bowling games.) I think point of the exercise was in the final ‘reveal’, wherein we discovered that we don’t need various classes we thought we would, and that the whole thing can be done just using a simple array. At this point we would realise the error of our ways, see how old-fashioned design methods lead to over-engineering, and live happily ever after.
It fell a bit flat.
At the time I put this down to a couple of things. One was that most of us didn’t know how to score bowling games. I suspect that the trainer, being American, had taken it for granted that most people would know. Presumably the reason for picking bowling as the example (rather than, say, cribbage) is its familiarity. The other thing was that it wasn’t immediately clear that the final version of the program would never write past the end of the array it used: a possibility that C programmers would inevitably take more seriously than a Java programmer would.
However, there was something deeper than this. This was clearly a toy problem, but people treated as if it were a real, complicated problem because - in a training situation - it is appropriate to “play along” with the example in order to allow the trainer to make his pedagogic point. This being so, it is always going to be a disappointment rather than a revelation to find the point is “don’t over-complicate simple problems”.
All this managed to create the impression that TDD is only suitable for problems that are essentially trivial.