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).
Currently at the Agile Development Conference in sunny Salt Lake City
I'm sure there will be many blogs about the event, so I'll just make a few notes.
talked about the intersection between Risk, Agile, and Peopleware.
As an industry, we have allowed ourselves to become dominated by a fear of failure. Most of the conventional methodologies are concerned with ensuring success by narrowing goals. The flaw in the CMM approach is that having the most "mature" team in the world doesn't necessarily help you build the most succesful products.
This is because too many organisations just won't allow people to tell the truth. Most people on the team know immediately when a project is dead but they're not allowed to act on that, so they're stuck trying to survive while doing obviously pointless work. Too many people in our business are simply not used to success. Success is empowering and motivating, people remember working on succesful projects for years.
We need projects that are more ambitious, so that the successes are more rewarding, and we can pay for them by killing off doomed projects earlier. Is it too much to ask that 1/2 our projects are outright winners?
"Never lose the feeling of success" That's what this business should be about.
Talking to Jim Newkirk and others from Microsoft's Patterns and practices group , one of their tasks is to improve the code examples that ship with the .Net environment which are often terrible: not object-oriented, no separation of concerns, that sort of thing. The really bad part about these examples, is that MS developers all over the world are using them as best practice and pasting them into their application code.
This is like the use of CFC's for refrigeration. It did the immediate job really well, but now we have a hole in our ozone layer that will take decades to repair, and many countries are still producing them. A short-term solution, a generation to recover.
Over beer, Eric Evans came up with a Law of Bad Programmers, that one bad programmer will consume the effort of two good programmers.
I was talking to Diana Larsen and asked her whether she found any differences when working with Geeks and other groups. Definately, she said, you need to know your stuff with Geeks because they will probe any weaknesses in your position, but once you've passed the test they're with you all the way. Other groups will play along and be polite and friendly, but not really get involved. That's why Diana likes working with Geeks but some of her colleagues won't touch us.
Secret Geek has invented TODO-Driven Development. As he says, it started as a joke but it's a cute idea. [From Strongly Typed]
The trouble is that now Microsoft have patented the infrastructure
(The actual patent is here) [From James Robertson]
Am I the only person who thinks this is getting ridiculous?