With few exceptions the QA organization and Engineering organization in software houses are given separate management chains. There are assorted rationales for this. Some firms like to set up the two in a kind of competition in preference to having them working in common cause to create good software. Some firms think of QA as a kind of auditing function who’s role is to temper a presumed tendency of engineering to fraud or self delusion. Some firms do this because they have put the engineering managers into a incentive structure that makes them likely to cheat to ship on time and they need to compensate for that.
This organizational choice results in tension, or worse. The two groups are torn between their common-cause, i.e a great product, and the day-to-day competitive games that are a result of the organization structure. As an illustrative example of how short term reward structures can generate polarization consider what happens when a bug is found.
When an engineer encounters a bug his reaction is to fall deeply into a trance state. This is the hunter’s mental state. He slows time down. He rises slowly and closes his door. To the hunter that moment is very valuable. He is in the presence of his prey. Even if it gets away all the information that is at that moment at hand is useful for stalking it tomorrow.
When the QA engineer encounter a bug his reaction is to shout hosanna. He bursts from his office to tell the boss. The reward he seeks is a bug sighted. To the software engineer this reaction is totally inappropriate. Yes, sighting the bug is a very key exciting moment but this excited reaction lays waste to that very valuable moment.
The software engineer takes that exciting moment’s energy and channels it inward seeking a fugue state. The qa engineer takes that moment’s energy and channels in outward seeking a celebration.
The organization structure just amplifies this. The QA engineer goes to his boss; who gives him a warm smile. The QA boss goes to the engineer’s boss and gives him a sly malicious smile. The Engineering boss simulates a gratitude for the valuable sighting. He then simulates the engineer. He asks if they made any effort to stalk the bug. “Can you reproduce it?” “Do you know exactly how it happened?” The QA boss thinks: “Ah you always want us to do your job.” They smile at each other in the shared knowledge of the absurdity of their situation. Later the engineering boss mentions in passing to the engineer that there is another bug in the bug database.
The only way to breakdown this is to allow the QA engineer and the software engineer into more intimate contact. That allows the QA engineer to observe and them model the behavior of the engineer. They they can share the reward to killing the bug. Which is; of course the common cause. Of course, you’ll have to set aside whichever adversarial model you bought into when you established the separation of powers.
Organization design is tough.
> The Engineering boss simulates a gratitude
Wow, does that strike a chord. Many a time have I seen the happy pair of QA’ers enter the tech lead’s office with happy grins, followed by the tech lead burying his head in his hands. Sometimes the whole party scampers over to a lowly developer’s cube, blocking him in and towering over him. Feebly, the developer makes a tentative guess at what it might be… and the QA folks bound away, leaving in their wake “I’ll assign it to you!”.
Pingback: Ascription is an Anathema to any Enthusiasm › QA: Impulse Control