Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Wed, 10 Mar 2004

Where's the creativity in test-driven design?

Michael Hamman has a couple of posts on creativity. In the first, he defines creativity as, in part, the desire to create a problem. In the second, he speaks of generating creativity by inventing friction.

Michael made me think of creativity and test-driven design. Consider my story of a refactoring episode. In it, I claim that the end result was surprising. And it certainly felt like something like creativity was going on. But where did the creativity lie? After all, what I was doing seems to be fairly straightforward rule-following: I saw two if statements that test the same thing, so I removed the duplication by creating subclasses. Then I made some code more intention-revealing. I iterated until there were no more "impulsive" rules telling me of code to clean up.

Is the creativity somewhere else in the TDD micro-iteration? Is it in the tests? Maybe, but not enormously. The tests are mostly responses to outside impulses (at the highest level, from customer desires). And the coding doesn't seem hugely creative, either, since it's mainly a matter of getting the next test to pass in a straightforward way.

I'm not even quite sure how to pose the issue, but it goes something like this: the end result appears to be the product of a creative process. However, the process, when examined, doesn't seem creative. It seems fairly mechanical, fairly rote rule-following. However, it doesn't feel mechanical from the inside: coding the dullest code test-first is nothing like the experience of sweeping the floor, though to the outsider they might not look intrinsically different.

Part of what's going on, I think, is that the creativity is distributed. It's more a matter of a series of small aha moments than fewer big AHA! moments.

But a bigger part, perhaps, is that the creativity lies more in retrospective discovery than invention. I said something like the following to myself: "Oh, you know that thing I created to get rid of duplication back then? Now I see that changing its name turns it into a potentially sensible - even suggestive - object in the domain model." Discovery. Or consider Ward Cunningham's story of Advancers.

An Advancer is a MethodObject. I first created an Advancer to hold all of the temps used in the otherwise unrefactorable advance method in WyCash.[...]

We came to think of computations in terms of the Advancers we would need. [...] The mere existence of Advancers shaped the way we thought. We got more done. We did it faster. We wrote less code. We had fewer bugs. [...]

We enjoyed the benefits of Advancers for many months before we discovered their real calling. We had been having persistent problems with a few tax reports. [...] Finally, out of frustration, we began to look around for other objects that might help, and there was Advancer.[...]

I don't know if Ward's talking about the same sort of thing I am. I shall have to ask him. In any case, understanding a bit more where my feeling of creativity comes from might help me get it more often - or more justifiably.

## Posted at 21:26 in category /agile [permalink] [top]