This heuristic can be used to make some crucial decisions about the future of the system and where the people developing it need to focus their efforts. It may also be an early indication that you need to think seriously about simply replacing the system altogether.
Suppose your system has a list of defects, and we'll assume that the list has been curated well enough to remove items that aren't true defects but rather feature changes or additions. The tipping point for quality occurs the moment your defect list has grown large enough and contains defects complex enough that there's a decision to mark lower priority defects with the status of "WON'T FIX", or to simply close them without fixing.
Once that happens, once you compromise to that extent on quality, you're starting on the steep downslope towards the immense pain of making changes to the system that break seemingly unrelated functionality. You're wandering into the wilderness of simple changes that take increasingly longer to make. Your ability to quickly react to market opportunities gradually erodes away.
How do you prevent this? The answer is quite simple - work from the perspective that anything more than zero defects is unacceptable.
I know you're laughing at this point. What a ridiculous thought! Software is far too complex! Defects are inevitable!
At some point in the history of software development, a person or group of people somewhere made a conscious decision to change from "defects are unacceptable" to "defects are inevitable". I completely understand that when computers were powered by vacuum tubes you were at the mercy of blown tubes and actual, living bugs causing short-circuits, but those days were well over a decade before I wrote my first Hello World program in BASIC in 1981. As I wrote in Waterfall Works!, the assumptions underlying many of the techniques we use and approaches we take today are based on the realities of computing environments in the 1950's, 60's and 70's. They don't need to apply anymore.
When I learned about Extreme Programming in 2000, the ideas of working on very small slices of features with rapid feedback, all backed by acceptance criteria and multiple levels of automated checks opened my eyes to possibility being able to ship software with near-zero defects at essentially no extra cost over the medium to long term. Suddenly, the impossible seemed possible, and yet another outdated assumption bit the dust. Since that time I've also learned about Exploratory Testing and other complementary techniques to drive quality even higher.
Since being introduced to these concepts, I've seen many groups and systems where User Stories are created in prodigious quantity, but not a single one has acceptance criteria. There are thousands upon thousands of automated checks such as unit tests, but defects constantly fall through that net because few people are taking the time to use Exploratory Testing.
If we simply change our mind-set from one of "defects are inevitable" to "anything more than zero defects is unacceptable", and think hard about what it would take to achieve that goal, we can reach the nirvana of great software with levels of quality of which we had only once dreamed.
Ideally, you simply realize the value of the change and start down that path. Failing that, though, ask yourself if the first rock has already broken a window. Have you simply closed defect reports without fixing them? Do you have a "Won't Fix" status in your tracking system, and if so have you used it?
So, has that rock already been thrown?
Comments
http://www.agilewhimsy.com/