Second Class Citizens, ReDux

I just posted this to the Software-Testing Yahoo Group:

I've seen the second-class citizen issue in many disciplines. I first read it explained well in one of John Bruce's Essays. Bruce puts it this way:

"There's one way I've found -- though certainly not the only way -- that you can tell a job has gone south. It's when the work suddenly focuses on its most rudimentary component. I'd been writing, coordinating, and publishing all the documentation at the USC computer center, a responsible position. Within a very short period I'd become nothing but a typist. Later, in other jobs, I'd find the work had suddenly changed from being a system engineer to being the kid who pushes a cart around, replacing coffee-sodden keyboards and used-up printer cartridges. That's a sign that it's time to go, or if you don't go of your own accord, someone will make the decision for you. When this happens, the window of opportunity isn't wide."

Now my words:

By it's "most rudimentary component", I suspect Bruce means the things that someone would see visibly if they did not understand the role. Without understanding, technical writing is transcription, helpdesk is call forwarding, project management is baby sitting, status reporting, and gannt charts. Programming is "just", translating from the language of humans to the language of computers, and testing is, say, "just" /verifying/ the translation was correct.

The steps that happen next are predictable: Management decides the work needs to be done, but shouldn't interfere with the busy business of production. They create two policies: First, to save money by hiring people who aren't very bright, and second, to create a /process/ to make sure those people who aren't very bright don't screw things up.

This is a self-fulfilling prophecy. You pay peanuts, create a heavy prescriptive process, lock people into roles you define ... and then you are consistently disappointed at the results those people produce. (To paraphrase Saint Thomas More: What can we say, but that we first create criminals, and then punish them?)

So, when you're told what to do by someone who's never done your job themselves, it might be time to go.

As I said before, this doesn't just happen to testers. This story is, to my knowledge, best documented in the role of the Quality Engineer in the North American Automotive Industry. I doesn't seem to be working out too well for them.

When I move into a shop, I do my best to impress my peers and clients so much that they will leave me alone to 'do my thing. When pushed to follow a process, I'll likely say something like "I appreciate your input, and I I'll keep that in mind when I make my decision on how to proceed." (Keep in mind, I've never worked in avionics or life critical systems.)

So far, it seems to be workin' for me.

Later, my Friend, former co-worker, and current writing partner Chris McMahon added this:

I have worked in life-critical systems, and our team implementing unique processes that contradicted the state of the practice in the late 90s (well, we thought they were unique until the Agile Manifesto was published) saved lives. Literally, saved lives.

If you see a better way, take the better way.

Thanks, Chris, I appreciate that.

More Metrics Schmetrics, still to come.