During the Producteering Breakfast series held at the SD Forum in California last month, the majority of participants (from the ISV community) held the view that a flawless and high quality product need not be the goal when attempting to build a successful product. Instead, a product that fulfilled customer expectations and which was better than competing products had more potential to be a ‘great product’.
So, instead of zero-defect software, what most users want is software that is cheap enough, fast enough, feature-rich enough, and available soon enough — that is, “Good enough”. Zero-defect software is often at the expense of time, functionality or cost – or all three. In fact, zero-defect software never guarantees that a product is ready or good enough to ship.
That leaves us with the question that’s been asked many times before: when is non-life critical software ready to ship? Is it when a certain date arrives, certain functionality built or some quality metric achieved? None of these criteria can actually result in software that is good enough to deliver. One aspect of an approach promoted by James Bach is to adopt a utilitarian method to deliver good enough software that is based on risk analysis. That is:
* Software is good enough when the potential positive consequences of creating or applying it outweigh the potential negatives
* Structured risk management needs to be applied to weigh the consequences and identify factors that make the risk more or less likely to occur
* Assessment of short and long-term consequences if the risk occurs
* Knowing the difference between important and unimportant, necessary and unnecessary
Many successful software products ship with dozens, if not hundreds or thousands of bugs, including most Windows and Mac product versions. However, it isn’t the number of bugs that matters; it’s the effect of each bug. In other words, knowing the risks of deploying software with known (and unknown) defects allows one to release software that is good enough, even to be the best!