“But I’m not broken…”

Periodically, I write.  And when I do, I try to write about helpful, wonderful things.

It happened of late that a close friend was having a rough go of things.  This happens not often but on a regular basis, and I’d suggested that perhaps it was time to talk to a professional about this.

That opened up a whole other can of worms, on top of the already-opened other-can of worms that we were struggling with.

“I’m not broken!  Not everything in my life is a mistake!  You’re not so perfect!  You think you’re always right!” (Etc., etc., you know how these things go.)

I finally came up with a brilliant way to describe the process.

You see, I’ve been to therapists before.  Some of them suck, some of them don’t, but that is determined mostly by what you want to invest in the process and whether or not the two of you can get on with mutual respect.  (This is not automatic, every therapist is not magically prepared to like and respect every client.)  But there’s a lot of misconception, too, I think about what therapy is supposed to accomplish.

Think of it like this:  (Good) therapy is like a good QA process in software development.  Barring any significant hardware issues, most final-release software will function pretty well until a set of environmental factors come into play – usually unforeseen by the original programmers or as a result of a post-release modification – and then maybe it doesn’t function as well as it should.  Perhaps there was a build interrupt during early development stages that introduced a bug, or maybe some kind of driver incompatibility exists that is only sometimes triggered.  Whatever the case, it happens, and it happens to everyone.  I’ve often heard it said that no piece of software every survived engagement with the public.

Regardless of how, glitches develop.  Sometimes that glitch means that the logic circuits go wacky and start spitting out junk results.  Sometimes it means that the whole system has to go into shutdown mode for a while to recompile the kernel.  Sometimes the glitch operates as a background routine, stealing resources from other processes until, bit by bit, it takes over the entire system.

Your QA engineer will be able to figure out what’s going on and help you apply a patch, bringing you back up to speed.  It can take a few different versions to step back up to a fully functioning system.  A QA engineer should not spend all his/her time trying to identify the offending programmer, nor should he/she try to fix what’s not broken.  The process often involves opening up libraries that you wouldn’t think would be part of it, but invariably it’s those files that hold the key to the glitch.

Often, once we get into the QA lab, we can pretty well figure out what the problem is, and maybe talking to the engineer is just a means of confirmation.  Thing is, our program may not involve doing QA ourselves, and even if it does, our QA method isn’t going to work as well as someone else’s for whom the perspective is more complete.

No one is immune from needing a little Quality Assurance sometimes.  Individuals need it, relationships need it, companies need it, families need it.  QA isn’t always about fixing things, sometimes it’s about testing to make sure things aren’t broken – and maybe even suggesting a nice feature to add on in the end.