February 17, 2011
Seriously. I recently spoke with a client who swears that software quality improved once they got rid of the QA team. Instead of making QA responsible for quality, they put the responsibility squarely on the backs of the developers producing the software. This seems to go against conventional wisdom about quality software and developers: Don’t trust developers. Or, borrowing from Ronald Reagan, trust but verify.
This client is no slouch, either. The applications provide real-time market data for financial markets, and the client does more than 40 software releases per year. If the market data produced by an application were unavailable or inaccurate, then the financial market it serves would crumble. Availability and accuracy of information are absolute. This app can’t go down, and it can’t be wrong.
Why Does This Work?
The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn’t work, the developers can’t say that “QA didn’t catch the problem.” There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.
As British author Samuel Johnson famously put it, “The prospect of being hanged focuses the mind wonderfully.”
Can This Work For You?
This can work if the application development team is held accountable for software quality. The consequences for bad quality must be so grave that the application team has no choice other than to focus their minds wonderfully on design, development, and testing. Most of the software I have developed over the years was sans QA team. When you develop mission-critical applications for large enterprises as a consultant, you better deliver quality or heads will indeed roll. You won’t get paid.
Responsibility isn’t enough. To be successful, app dev teams must create test harnesses, create test plans, and use testing tools. But, because the developers know where the bodies are buried in the code, they can focus their efforts on the most brittle parts of the applications. The level of effort will depend on the type of software. The end result could be better quality and faster release cycles.