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

Thu, 06 Feb 2003

Personality and process: a story

Esther Derby passes along this in response to my riff on process and personality (which you'll find embedded in the story below).

Here's a story (a true story, from just last week):

I was talking the other day to a woman who works with companies to improve their project-ability.

She had a potential client who was set on instituting some sort of rigorous PMI-type project management. Most of the people who were actually working on projects found the thought of PMI-type management horrifying.

When she probed further, she found that the potential client was reacting to the stress-related death of a 30-year old project manager on his staff. He never wanted that to happen again. He desperately wanted to reduce the stress his development staff and PMs were living with. His answer, the answer that would reduce stress for *him* was a mechanistic model of project management.

When the consultant keyed in on the difference between what would reduce his stress and what would reduce stress for the staff, they were able to find a different, and more fitting, solution.

## Posted at 19:37 in category /agile [permalink] [top]

How micro should a test-first micro-iteration be?

Canonical test-driven design uses very small micro-iterations. You write a test that fails, then you write code that makes it pass, then you maybe refactor, then you repeat.

I tried it that way for about 2000 lines of Java code. It didn't stick. The experience has caused me to write fewer tests before writing code, but not always just one. Sometimes it's one. Sometimes it's more.

Why not? Why not do it the right way? It's because I don't believe there is a right way. I wrote the following in an upcoming STQE editorial:

Of course, I can justify my approaches, showing how they're grounded in careful reasoning and historical experience. But let's be frank: my approaches are not just compatible with my personality - they're derived from my personality. And so are everyone else's, even though they also justify their approaches with history and reason.

Every article on methodology implicitly begins the way this one did: "Let's talk about me." Methodologies and techniques are developed to help their developers get ever better at what they do, while allowing them to be who they are. So those people who like things laid out as a whole for dispassionate review create and refine inspection techniques to make them better at such review. Other people feel unsettled without interaction and exploration, so they create and refine test-driven design and pair programming to help them do that better.

(There are similarities between this position and Kent Beck's oft-quoted "All methodologies are based on fear". But I think more than fear matters.)

My approach to test-driven design balances two forces: my desire for interaction and exploration, and my feeling that I'm building a whole thing that I need to grasp in some sort of entirety. I get pleasure from both, so I devise a way to do both.

Like most people, I operate mostly on autopilot. But I am often conscious, when having just written an assert, of wondering whether I'll learn more by writing another test or by writing code. What I do next depends on my answer.

## Posted at 13:46 in category /agile [permalink] [top]