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.