Schedule and Events



March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email: Matt.Heusser@gmail.com

Tuesday, November 18, 2008

JabberWocky -- II

There's more to the poem than a good URL.
First, head off and read JabberWocky.

The Poem is actually a poem-within-a-story - it is a poem that Alice reads in Through The Looking Glass.

What's really interesting is Alice's Reply after reading the Poem:

"It seems very pretty," she said when she had finished it, "but it's rather hard to understand!" (You see she didn't like to confess even to herself, that she couldn't make it out at all.) "Somehow it seems to fill my head with ideas--only I don't exactly know what they are! However, somebody killed something: that's clear, at any rate---"

Of course, Jabberwocky is, more or less, pure nonsense - a bunch of buzzwords and fluff with a couple of actual English sentances thrown in. Just enough real words to make you feel as if there is something to "get."

Does that sound familiar?

If we search and replace a few key words, Alice could very well be talking about requirements documents from some projects I have worked on:

"It seems very interesting," she said when she had finished it, "but it's rather hard to understand!" (You see she didn't like to confess even to herself, that she couldn't make it out at all.) "Somehow it seems to fill my head with ideas--only I don't exactly know what they are! However, customers will be able to do some new things: that's clear, at any rate---"

Many project documents take this approach - especially one where there is little agreement on what should be really done. So we paper over disagreement with big words. (Example: Can't agree to use a touchscreen, mouse or keyboard? Call it "The Input Device." Can't agree on how to run the project or what metrics to use? Simply insist that the project be "Quantitatively Managed." Can't agree on what a good organization looks like? Call it "Mature" or maybe "Agile.")

However, we have social problems with admitting that something is wrong ...

A) We are afraid that the document is good, and we're the stupid one.

B) We are afraid that we'll look dumb; that when we say "I don't understand this", the other person will pat us on the head and tell us that someday, indeed, we'll get it, when we grow up,

C) The team has obviously invested considerable time and effort in developing these documents. Saying we might as well start over can be taken, as, well, an insult to the professionalism of whoever prepared this document.

I don't have any easy answer to this problem. I do know that calling out dead-fish communication in any form can help. (It doesn't have to be bad documentation, it could be hit-and-run management, for example.) I do know that after living with bad documentation once, if you call things out early, it is sometimes possible to prevent them on the next project. (It works like this: "I know project X is coming. I know Alan the Analyst is working on documentation in a corner. That's just what we did on the SuperWidget project. We don't want another superWidget, do we?")

Sometimes, there's a little voice in our head that there is a man behind the curtain. It's best to admit it than pretend to be talking to the great oz.

No comments: