![Free eBooks of IT [BooksOfAll]](https://www.booksofall.com/wp-content/uploads/2022/06/booksofall-logo-2.png){kind=logo}
The Hazards of Being Quality Guy
Perhaps you’ve seen the Dilbert comic about Process Girl. At a meeting, the Pointy Haired Boss introduces Process Girl as “the one who has the answer to everything”, at which point Process Girl chimes in parrot-like with “Process!” She then denounces the meeting as inefficient because the participants have no process to describe how to conduct a meeting. By a unanimous vote she is expelled from the meeting. As he escorts her out of the room, Dilbert offers by way of consolation “at least you lasted longer than Quality Guy.”
And now I must reveal a shocking truth … ladies and gentlemen (rips open shirt to reveal spandex body suit with “Q” emblazoned on the front) … I am Quality Guy. I am that much maligned coworker that you love to hate. I am your local ISO champion, the leader of the Software Engineering Process Group and the mongrel who overflows your inbox with links to articles about process improvement. I’m the trouble maker that asks embarrassing questions in meetings like “why aren’t we doing code reviews?” and “where’s the design documentation?” I am the one that dilutes your passionate discussions on J2EE and SOAP with hideously unfashionable prattle about CMM and the SEI.
And like my namesake in the Dilbert comics, I am ostracized by my peers and colleagues. I am renounced as being a “quality bigot” and dismissed as impractical and too focused upon meta-issues to actually achieve anything worthwhile. I am perceived as an impediment to real work and characterized as a self-righteous, holier-than-thou elitist. My suggestions of ways to improve my team’s work habits are interpreted as personally directed criticisms and thereby evidence that I am “not a team player”.
From my point of view at the periphery of the team, the earnest activity of you and your geek friends seems somewhat farcical. You seem to be perpetually distracted by the shiny new technology toys that the vendors are constantly grunting out. You are hopelessly addicted to novelty and consumed by the frenetic pursuit of the latest bandwagon. You seem to be entirely unconcerned that “beta” is synonymous with “buggy” and “new” with “unproven”. The projects of my successive employers march by me like a series of straight-to-video movies, each baring the same formulaic plot wherein only the names of the participating technologies have been changed to protect the innocent. I feel compelled to yell out “stop!”, “think!” and “why?”, but it is hard to be heard when you’re in geostationary orbit around Planet Cool and in space, no one can hear you scream.
Friends, this is what it is to be Quality Guy, and it ain’t no party.
If you think you or a loved one might be in danger of becoming a Quality Guy sidekick, let me offer you this one piece of advice – never reveal your true identity to your coworkers. It is a sure recipe for alienation and isolation. Keep your shirt closed to the top button, so that your superhero garb will go unnoticed. Eschew all quality-related terminology from your public vocabulary and substitute terms from the jargon file1. Hide any books you might have that do not relate directly to a technology.
When it comes to development practice, with a little ingenuity you can institute a number of quality-related practices within the sandbox of your own development machine, without needing to reveal to others that your sphere of concern extends beyond the acronymic:
- If you find yourself in an environment without version control, install a free version control system such as CVS or CS-RCS on your own machine. You can at least maintain control over those files that you are immediately involved with.
- If there is no prevailing coding standard, employ one for your own code without revealing to others that there is any guiding hand of consistency in your code (that would be un-cool).
- If there is no unit testing, write your own in a parallel source tree visible only to yourself using the free xUnit package appropriate to your platform.
- If there is no design documentation, reverse engineer the existing code into some hand-drawn UML diagrams and then stash them away where others won’t find them, keeping them just for your own reference.
- No requirements? Start your own mini-requirements document as a local text file, and question the developers and senior team members around you to try and flesh it out. You can at least try and restrict uncertainty with regard to your own development objectives.
Remember, the secret to surviving as a Quality Guy is to keep your true identity a closely guarded secret. That way you can still be one of the gang and remain non-threatening whilst still being able to take some satisfaction from the limited degree of quality enforcement you can achieve through isolated effort.
