To paraphrase Tom DeMarco, I am all in favor of product standards. After all, Product standards are the reason that I can buy a Double-A battery from any manufacturer, plug it into my CD Player, and not worry about compatibility. For that matter, it's the same thing with CD's, DVD's, VHS, and the players for each type. Sony, Samsung, they are all the same, and they interchange well.
Process standards - how to build the Double-A's - well, of those I am more dubious. The truth is, I really don't care how the two terminals of batteries are developed, as long as they are the right size and send the right amount of electricity at the right time. That's a big part of why I signed the Agile Manifesto - it explicitly says that we value:
individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
So, when people rush to standards, I hold back a bit. Having a standard means saying "We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things."
My Father, Roger Heusser, spent thirty years as nuclear chemist and executive in the US Department of Energy. In other words, my dad is a scientist - he taught me to experiment, learn and grow. My mother, a music and grammer-school teacher, taught the same.
... and I've got a problem.
I have been teaching software testing to two corporate classes, about an hour a week, for a few weeks now. Before I came in, the group knew 'how' to test, or, at least, they how to use a handful of templates to produce some impressive documentation, and, along the way, to make sure the happy path of the software mostly worked, some of the time ... more or less.
I challenged that. In class, we did some empirical experiments that demonstrated that exploratory testing and documenting only the defects found resulted in more bugs found in less time. I also had students describe how much fun they had, on a scale of 1-to-10, and students that did exploratory testing scored much higher than the people who were assigned to create documented test scripts and then execute those scripts.
Now I am finishing up equivilance/bounds, moving into scenario testing and other methods. But there's a problem.
Both classes want a 'cookie cutter' way to do development. They want a standard. They had a standard, and I've taken it away by proving empirically that they can do better work themselves.
But they still want a standard! They want something to cling to!
Yet there are no easy answers. (Or, I suppose, yes, there is a quick and easy way, but it's not good.)
Eventually, I hope to give the class a very wide and broad tool box, from which they will select how much of which tool to use in the limited time they have to test products before release.
I have no standard, and I am okay with that. The question is ... how can I help make the class ok with that?
4 comments:
Matt,
It's worth making a distinction between standard practices (which your students are seeking but will never find) and standard principles (such as quality, joy and so on that we can really all relate to).
The way to map between the two is to continue to expand your tool kit - so that regardless of the situation, you have the tool that is appropriate to allow you to realize your goals.
Standard practices (agile or not) will only work in standard situations - and we do not have the ability of controlling our situation so that it is always the same. Or at least, I would probably find such a managed situation pretty boring after a very short while.
I would guess that having a scientist and a musician as parents has given you a huge boost in this light - I too find in teaching that most students are looking for a formula of practices, and have not yet made that leap...
Jim
Matt,
I've been thinking about some similar issues, from the development side. Your post triggered my putting those thoughts into writing (http://blog.gdinwiddie.com/2007/01/16/make-it-work-before-you-make-it-standard/).
Matt,
My hats off to you; taking on a challenge like teaching people to THINK and abandon their comfort zones is very ambitious/optimistic.
I can appreciate the apprehension and uneasiness of your students. From, all be it, my very left-brained perspective, it’s conceivable there are efficiencies thought (rightly or wrongly) to be gained by documenting the development/test processes in order to pass along knowledge to subsequent team members. Though it ignores the fact new programs to be developed or tested, open up new and different potential approaches and or class of bugs to be fixed; yet previous knowledge of the prior test procedure is a good starting point/anchor.
In any event, starting with a standard doesn’t negate further exploration. Often the hardest thing to do is Get Started. To some, suggesting that one discard those potential process-template/handcuffs may suggest there are as many permutations to approach/test a body of work as there are snowflakes. Very intimidating and (rightly or wrongly)seem too aleatoric and meandering.
I’m struggling with the concepts of exploratory, contextual and Agile. {They seem to meld together like advanced physics, mathematics and chemistry :-)
Just picked up a copy of Brooks’ The Mythical Man-month; talk about depressing; it a wonder anything gets programmed! :-)
All The Best
Ken
paragon399@yahoo.com
They don't just want a standard, do they? If they wanted that alone, you could give them one. No, they want a standard that has two attributes:
1) A standard that causes excellent testing.
2) A standard that will not require them to learn how to test.
This does not exist. You can't give them something that doesn't exist. You can only pretend to give them something that doesn't exist.
Many consultants have gone down the pretending road. I think you're too good for that.
-- James
Post a Comment