Firing Your QA: Worst. Idea. EVAR.

This blog post comes to you courtesy of Mike Gualtieri at Forrester, who has demonstrated that either they’re completely clueless or they’re possibly generating analysis at random. Who knows. You can read the offending piece here, but I don’t recommend it if you’re either a developer, programmer, QA, QC, familiar with any of these people’s roles, or don’t have a strong stomach for ignorance.

In this piece, Mike advises people to fire their QA teams and make developers directly responsible for code quality, arguing that it will improve code quality. Fun fact: it absolutely will not. If it did, that means the QA team was not doing their jobs. And that your organization failed to implement something it should have already.

Let’s talk about some metrics – much more important metrics – that Mike left out of his article. Bugs get fixed faster, okay, and maybe there are a few less. Now what about feature requests? What about next version? What about improving existing features? All of these critical development functions just got more or less thrown out. What about code produced per programmer per day? This is a metric people are fanatic about (despite that it’s arguably the worst metric) and most assuredly dropped dramatically.

First and foremost; QA’s job is to serve two key functions. One, they test the product thoroughly to ensure a minimum of bugs and problems. Two, they serve as an interface between developers and customers, so that developers can focus on their work. A third function that some shops implement is to give QA prioritization authority; that is QA decides which bugs are break-fix, showstopper, and which are just feature requests. Again; SOME businesses do this. Some let programmers decide which bugs need priority. Most have a dedicated resource or resources to prioritizing bugs in some form though.

And you want to dump ALL of this onto programmers? The only word for you is “completely clueless.”

First and foremost, talk to a programmer sometime. Ask them what they want most in their office environment. Answer number one? Less distractions. Programmers do not want to be interrupted constantly by meetings, phone calls, and other minutae; it disrupts their workflow and concentration. Writing code is not just “bashing on a keyboard for hours.” It requires focus to recall which function does what, where you are exactly in the execution stack, and so on. Ability to handle interruptions is not a measure of skill of a programmer, either. Code is complex. Nobody can keep everything in their head while handling an irate customer on the phone.

UPDATE: It was pointed out to me that I neglected to mention that QA/QC ALSO is responsible for creating test cases, iterative testing routines, and so on based on customer feedback. These are some of the most time consuming tasks in any QA/QC department, by far.

Second, if programmers are not already directly responsible for the quality of their code, that will never be the fault of having a QA department. It is a management failure on your part, period. Developers should and must always be directly responsible for the quality of their output, not their quantity. (Again, goes back to my arguments against using “lines per day” as a performance metric.) I won’t waste time on the dozens of ways to implement it; suffice to say that if you haven’t implemented it, then the blame is at management’s feet.

Third, it creates a culture of fear. This is absolutely the worst, most incompetent and wrong-headed method of management out there. The amount of popularity it is gaining is just horrifying. People who are afraid for their jobs may work harder, but you can be damn sure they are not happy. And they will look for the nearest exit as fast as they can. Churn in developers for a complex application doing anything is a bad thing. Not to mention that study after study after study shows that unhappy employees produce less, are less healthy, are more likely to take action against their employer, and will not stick around.

So let’s summarize: Mike’s advice is to A) increase distractions for programmers B) implement something that should already be implemented C) create a culture of fear in your workplace. And that by doing these three things you will magically be endowed with better quality code. Here’s a hint for you: absolutely not. (Okay, so it’s not a hint as much as a statement of fact.) Doesn’t matter what you’re doing. Fix your management structure to make developers responsible for code quality instead.

So what’s MY advice? A) REDUCE distractions for programmers; do you REALLY need daily status meetings at 10:30AM? Reschedule. B) Implement responsibility for code quality with your QA/QC department. C) Reward programmers genuinely for accepting responsibility and improving their code quality. Recognize the people who work to make your product or business possible. D) If you’re using “lines per day” throw it away. Rewarding 50 buggy lines over 20 quality lines; whyyyyyyyyyyy?! E) Encourage risk-taking. Innovation depends on, starts with, and ends with your developers. If someone suggests a new feature that’s unrequested, don’t dismiss it out of hand. You may have a new product on your hands.

I just cannot believe that anybody would think this is legitimate much less trustworthy advice. Does nobody bother to talk to the people who it affects? Or do they just talk to management about their “predicted cost savings”?

And for the record; yes I do programming sometimes. But I actually consulted with several people who program at major companies for a living. While most of them have a love/hate relationship with QA/QC, they agreed with me. And all of them said that if they were subjected to the culture of fear Forrester encourages, they’d immediately start looking for work elsewhere.

4 Responses to “Firing Your QA: Worst. Idea. EVAR.”


  1. Tweets that mention Firing Your QA: Worst. Idea. EVAR. | Error404 – It's A Blog -- Topsy.com

    […] This post was mentioned on Twitter by Martin Glassborow, Scott Francis and The Cow, Phil Jaenke. Phil Jaenke said: [blog] Firing Your QA: Worst. Idea. EVAR. – http://wp.me/pXP90-4E – Distracting developers and a culture of fear. GREAT idea. Not. […]

  2. Friday links, 3/4/2011 edition | making IT happen : an infrastructure blog

    […] Firing your QA: Worst. Idea. EVAR. [Regardless of what Forrester says] […]

  3. Evgeny

    I feel that you misunderstood the piece, there are several problems with the current DevQA model that causes lower quality overall – no matter how professional your QA team is.

    Some things that I know for true:
    1. Developers really love to have as little responsibility as they can get by with.
    2. Developers have no idea who their customers are, what they need, what they think, etc…

    Now, while Mike suggest firing your QA team – he does not suggest firing the QA. He actually suggests that your Quality Assurance will be done by the developers, who wrote the code in the first place — and who by their state of “being in focus” have not checked their own code and did not realize that it was full of bugs (which usually are not all caught by QA teams)

    I would like to compare this to a writer that wrote a chapter in a book, and did not read it twice (3,4,5,6 times) before he sent it to his editor. Most developers behave exactly like such a writer.

    By dumping extra responsibility on developers, and attaching them much closer to the customers — the business will likely create software that is more tuned to customer needs, and will have much less bugs in it. Hopefully it will also mean that unprofessional developers who can’t work in such a way will get flushed out and replaced by better ones.

    And I do agree with Mike that software quality will be much higher, so dumping your QA team (or not having one in the first place) is a very good idea imho.

    Although, not practical for most places, since the developers are so scared of responsibility and so don’t care about customers that the company should not exist in the first place.

  4. Phillip

    (Note to self; log in as CORRECT user. Wups!)

    Evgeny, you do raise some fair points which actually I do agree with.
    Absolutely, many developers do try to avoid any sort of responsibility for their mistakes and errors. There’s a the folks who try “it’s 20,000+ lines of code, mistakes happen, can’t blame me!” And in the newer generation I’ve seen a lot of “well it’s not MY fault I just did what the book said!”
    And absolutely, a lot of developers have NO idea what their customers want. It’s not in their job responsibilities, and it’s not communicated to them effectively.

    Firing QA teams however, fixes neither of these problems. It just removes a critcial second look from the process. Like it or not, that first excuse, isn’t an excuse. Mistakes DO happen. And when you’re talking about 20K+ lines of code, it is completely unreasonable and a complete waste of time to expect the developers to accept responsibility for the entire thing. Their job is to develop the software.
    The same goes with attaching developers to the customers. Do you want them doing what they were hired for, writing quality code which requires intense focus and concentration, or spending all their time fielding calls from customers who are irate about their decision to replace periwinkle blue with sky blue? (THESE THINGS HAPPEN!)

    And believe me, these are things that we’ve discussed at great length here as a startup. One of our decisions? We don’t have a QA department. And it’s not for any of Mike’s honestly absurd reasons at all. One, we don’t have the money. Two, we have a very small team – just two of us. Three, both of us are intimately familiar with the ins and outs of each other’s code and responsibilities, so we become the second set of eyes. Four, we have very few customers to support and very few support incidents expected.

    But we also know that as we grow, we can’t afford to spend time on these things. That doesn’t mean avoiding responsibility; if something’s broke, it IS the developer’s responsibility, period. It’s QA’s job to keep that brokenness to a minimum, and keep those fixes in house. It’s BusDev’s responsibility to take customer feedback and deliver it in a (hopefully sane) form to developers to act on. The developer’s responsibility is to take these items and act on them.

    Ultimately, as we’ve learned, your choice is either you have your developers focus on your code and getting it done, or you ship a lot of broken code that’s been turned into a hodge-podge of competing requirements and is generally a disasterpiece, even if that part isn’t visible to customers. My partner has been dealing with such a situation for several years. Customers provided direct feedback to developers. Who then went off on tangents for specific customers, that competed with tangents for other customers, and so on. Some of that was the result of poorly organized and managed QA and business development. Firing these people is completely counterproductive and foolish, when the problem is how they’re being managed and doing their jobs. NOT their presence as an insulator.

    It’s also proven that software quality over that time has declined significantly from these exact issues. Developers had time taken away from them that needed to be spent writing code and improving it, to address customer communications and test cycles on their own time. As a result, code stagnates, because there is no time to get ahead of it. Instead you’re permanently playing Build The Automated Test Suite and Whack-a-Bug, which are incredibly inefficient and wasteful uses of developer resources and time.

    QA will and always has been better served by people dedicated to that task, who can devote all their time and effort to finding bugs, instead of robbing your development team of resources they need to improve and fix your product. (Or you’re in a permanent cycle of hire – lose to burnout – replace.) Without them, you will stagnate, no matter what someone named Mike thinks.