Engineers Should Not Perform Extensive QA

Many times I’ve received religious doctrine from well-meaning technology leaders, sort of like technical Communion, regarding how engineers need to take responsibility for the quality of their code, to the point where QA staff is not necessary. Indeed, I’ve even watched it work. But the times I’ve seen it and regarded it successful represent a fraction of the times where it has proved to be a needless sacrifice of quality. Worse, it is more expensive in the long run, and perhaps most unfortunately, I’ve often noted that it slows down the delivery cycle.

If you’re a manager in an early stage startup reading what I just wrote, you’re probably thinking “Well, okay, it's slower. So what? At least we didn't have to increase body count.” Granted, there are times when high quality really doesn’t matter, and that’s likely one of them. However, if you’re in a Series C startup or later, I urge you to take a good look in the mirror and ask yourself why you trust your Series A parlor tricks to gain for your product a winning position in a competitive market. 

The difference in mindset

I have run technical teams for over twenty five years, with QA resources as well as without. Let’s look at the factors as I’ve studied them. 

To begin with, software engineers are Creators with a capital C. As someone who has long admired the craft and creations of these remarkable artisans, I assure you that as scientific as it sounds, good software engineering is a Creative endeavor. It involves designing, inventing, sculpting, crafting, refining… you get the point. Software engineers who do it well are rightfully proud of their creations. That act of conceiving and creating fantastic systems is how they prove their worth. They are not better regarded, nor better paid, for turning over every leaf to try to find a flaw that could be discovered by a user.

Now consider the professional QA resource. This person’s solitary mission is to beat on the software from every angle, no matter how dreary, repetitive, or difficult the process, in order to break it and find the one thing that an engineer did not think of. I once saw a QA person write a script to issue the Print command eighty times a second. Most people would ask why that matters. Maybe it doesn’t, but that question never occurs to a QA person, and there’s enormous benefit from applying someone to your solutions who does not judge or dismiss the method of breaking before attempting it. They’ll find problems no one else can remotely dream of. When a QA person crashes the program or finds a flaw, that person Celebrates with a capital C. It’s how they prove their worth. They are in fact better regarded, and sometimes end up promoted, from their ability to expose issues.

Leaning into strength

I am religious about playing people to their strengths. I would never assign the designer of the Chrysler Building to inspect all the rivets and make sure they are properly positioned and tightened. If I were to assign them in that way, I should expect poor results. It is not what they do best. Nor would I ask someone who has been extensively trained to find the flaws in construction to design a building, let alone a marvel of design. In both cases it’s not in their nature nor in their self-worth calculations to trade places. And unless you don’t care about quality, it’s counterproductive to ask it of them or expect them to perform it well. 

Some of you will point out that the creative engineer can create software to test her software. But even doing that, she still needs to think like a career QA person to really exercise the system in everything it's expected to do. There’s an unconscious bias, when engineers test their own work, that the system will work more or less as intended. It’s the same reason writers seek beta readers when they finish a piece – they’re too close to the work to see the flaws. In software, that myopia is deadly, as it causes significant issues to slip through.

Conclusion

The bottom line is, good QA resources are better at QA than engineers are, and they often cost less. What’s more, when you take engineers away from their core strengths to do QA, or any task they are not necessarily suited to do, they’ll do it slower. If they are responsible for quality, there will be problems missed that they will eventually have to backtrack to repair, sometimes involving refactoring of their solution. Wouldn’t it be best to apply them to what they are uniquely suited for? Instead of refactoring, they could be designing the next Chrysler Building for your team and company.