Now and then, a manager will make a decision to meet a software delivery deadline by bypassing a QA process, because in their mind, meeting the deadline is more important than assuring quality. They may send something broken, but at least they send something broken on time. To be fair, this is not always their fault; their own managers may be the ones enforcing this world view, and adhering to it, however nonsensical, may make a major difference in their annual raise.
Those of us who actually produce work product for a living tend to think of things in terms of whether or not they work, not when they are delivered. The when is largely a measure of how inaccurate the manager’s arbitrary schedule was, nothing more. It took as long as it took to make it work, and that’s that.
I propose that any manager who elects to circumvent a QA process in order to rush software toward a deadline must read and sign a document stating the following:
I’m a manager, and as such, I know way more than the QA department’s trained professionals about the chaotic nature of software changes. I acknowledge that one simple change can cause side-effects that are not obvious, but I’m certain that this isn’t the case here because my mind is more powerful than any mere QA process, and I know better than the entire QA group. If for some reason I’m wrong (which I am not), I will buy everyone a pony of their choosing.
This may seem a little harsh, but when I was starting my career, I became the delivery manager and the QA department, making me the gatekeeper between a deliverable and our customer. I had a total quality failure involving someone who was new to a software module and building it for the first time. Twice in the same week, he assured me it was good to go, and twice in the same week, I trusted that and delivered something that was fundamentally broken. We worked together to resolve the problem, but the lesson I learned was that trust and judgment are not as powerful as a robust QA process. When I elected to bypass the QA process, I was essentially making an implicit declaration like the one above. Of course, I was, in effect, saying that I knew more than me, since I was both the delivery manager and the QA department 🙂
Reagan said it best: “Trust, but verify.”
This is true in a larger scale, not simply limited to QA. We recently had a critical module within one of our releases delayed for months with major problems. Reason being the person in charge trusted their #1 developer, who in turn trusted his top 3 guys, who in turn trusted their teammates, etc. Trust in your colleagues is good, but there was no verify part. So there was not sufficient oversight to catch any missed requirements or false assumptions.
Now, where’s my pony?
You don’t get a pony unless your person in charge signed a document like the one above 🙁
You’re right that the larger case is a trust vs verify issue. QA is the verify part, and decisions to not use QA are the trust part. Ideally, both would go together.
Your example reminds me of a concept called “collective ignorance” which is similar to, though not identical to, “group think.” Collective ignorance happens when a group of people are exposed to a stimulus that should cause them to react, but none do. If enough of them do not react, the others will begin to think that the non-reacting people know something that they don’t, thereby explaining their lack of reaction. But in reality, that isn’t the case; just about everyone is waiting for someone else to react so that they don’t feel like they’re missing something. It happens because nobody wants to be the one acting silly or looking like a noob.
Chances are good that at every level of the organization, many people were thinking of questions that begged for answers, but because nobody else showed any outward signs of doubt, they kept their silence. I usually don’t run into situations like that because I question just about everything, which is a great thing in a good company, but rather detrimental in a bad company where people don’t like to admit they have no answers.