At ADC2004 I was chatting with Ward Cunningham about the origins of Test Driven Development. He said that, for him, it came from working with a group that was working in parallel on the same code base. The domain was mathematical and so pretty straightforward to test, so he pushed the testing forward to make sure that they weren't stepping on each other.
More interesting, he introduced test-first to influence how the pairs (yes, they already had pairing) worked together. If you have two coders working on a problem, they'll each bring their own ideas about how to do it and the result is likely to be a long argument and not much productivity. With TDD, they can progress in small steps, chipping away at the problem until they come to the difficult bits. These might not turn out to be so difficult after all, or there may be a better third solution, but now they've focussed right on the core of the problem.
This resonates nicely with Tim Mackinnon and Oli Bye's experience that it's easier to argue (productively) over tests than code because there's less ego involved. When the test is clear, the solution often just falls out.
I hadn't realised before the extent to which Ward sees TDD and Pair Programming as complementary. He mentioned visiting one site where they just couldn't make TDD work. "Are you pairing?", he asked.
This also resonates nicely many of the comments during Chris Matts session on Real Options. At the micro level, TDD allows programmers to concentrate on what they know and defer decisions as late as possible. This is a key principle of Agile and, incidentally, is supposed to be one of the key indicators of highly skilled practicitioners (I must find a reference for that).
Posted by stevef at June 26, 2004 2:16 PM