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?