If I were to ask, “What is the definition of software quality?” in an open forum, I would receive hundreds of answers, many of them citing the IEEE or personal definitions. What if I were to say that most of those definitions were wrong, or at least irrelevant; that most of the time, quality does not matter? I call this the “devil’s advocate” position, and I think it’s worth discussing.

The argument goes something like this: Quality only matters when it affects the customer’s happiness, resulting in nonpayment due to issues, threatening to cancel or not renew, deflecting to a competitor, or dealing with exorbitant maintenance costs. There are things that do matter, but the logical reaction to them is not delivering perfection. Instead, it should be asking the opposite: What is the minimal amount of investment we can make in testing to get the product out the door to start making money? For that matter, what is the minimal standard we can use—just enough quality—knowing we can leverage our customers as a test bed? They’ll tell us about the bugs and we’ll fix them. This positions quality by how it impacts revenue.

But why stop there? Here are a few more arguments against quality in testing—or at least my understanding of what quality means in testing. Let’s really be the devil’s advocate.

• First to Market Is Most Important

Sometimes testing slows down release, and slowed release reduces cash flow for the month, the quarter, and the year. If the competition captures the market before we get our software out, then the pursuit of “quality” could be disastrous to the bottom line. In other words, if we define quality in terms of revenue, sometimes the right thing to do is to live with defects.

• Human Testing? Why? We Have Tools for That!

The right tools lead to high-quality code. Engineers trained in modern tools can identify and catch defects early in the process. The right software and technologies combined with open source tools eliminates the need to invest in other quality measures. If the tools don’t find defects and our developers don’t find defects, then just ship the software. (Besides, if a bug gets through, the customer will report it.)

• Let the Process Take Care of It

If the team follows a labeled process, such as agile, Scrum, or Capability Maturity Model Integration, then it must be good, right? After all, doesn’t the very word agile mean “good”? If the team says it is agile, then quality is guaranteed!

Besides, investing in a new quality system would cost money, and quality is not just revenue, it is revenue minus cost: profit. Additional processes to “improve” quality would really just slow the team down, creating still more cost, and thus, by definition of the word, decreasing quality.

• You Get What You Pay For

At a dollar or two per download of our app, customers don’t expect too high quality. They might get frustrated, but they won’t feel too bad; the application was only a dollar. Software teams can slowly burn down the defects identified by our customers as time and money allows. Given the right price point, even negative comments here and there in the online store won’t deter most customers. Ninety-nine cents just isn’t that much of a risk. No one expects NASA-quality software at that price.

• Hear No Evil, Speak No Evil, See No Evil

If sales are up and subscriber attrition is low, why rock the boat with new processes to address a quality problem the company doesn’t have—at least according to revenue metrics?

• It’s a Supply Chain Problem

If there are problems with the software, then there are problems with the vendors who built the basic software; the in-house teams just integrate the vendor software into the core. Software quality problems go back to the vendor, and the way to manage the vendor is to focus on the what —requirements—not the vendor’s process.

Sympathy for the Devil

All of these are real excuses I have heard over the years to not improve quality. In some cases the arguments may seem perfectly legitimate, but I have learned to be more than a little bit skeptical. Sure, a big social media company might get its own users to test at one point in its growth history. But companies that are not big social media platforms at a magical point in time follow that strategy at their peril.

Getting rid of the knee-jerk devil’s advocate, which protects whatever is happening now, and instead talking about real improvement is, in my experience, a very healthy step.

Getting to Real Improvement

Valuing software quality is good. Having a definition of quality that everyone on the team shares is good, too. Getting stuck on that definition can sometimes mean retreating to the devil’s advocate stance.

That is not so good.

When people ask, I suggest having a definition of quality, yes; but don’t take yourself so seriously that you become stuck in your ways. Instead, realize there is no silver-bullet solution for addressing software quality, because the challenges change daily. The fun begins when people realize they need to try new approaches and throw away the fear of challenging the old ways—when people stop saying, “That’s the way it has always been done.”

My Quality Soapbox

I take this challenge to rethink quality with me 24/7. My quality soapbox is with me at cocktail parties, weddings, graduations, informal gatherings, sporting events, on airplanes, trains . . . . I’m happy to stand on it when someone asks me about what I do for a living. I often forget to leave the soapbox at home (my wife sometimes reminds me afterward of this) because when you believe in something so much, it becomes part of you, and if you’re not careful, it will define you. People sometimes don’t want to be challenged. Instead, they want an easy answer, to have some laughs, and to feel good about themselves.

Perhaps I need to sit down, shut up, and stop challenging the status quo, or give these folks a break and stop caring more than they do. Or perhaps I shouldn’t—what do you think?