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
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
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
How micro should a test-first micro-iteration be?
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
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
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
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