The decision of when to release software is a balancing act between many different things. How many features, how many bugs are acceptable, time to market, price, available resources, market demands, and competition. The people at the software company have to balance these forces and decide when it is the right time for software to be released.
If we were to wait until our software was bug free (relatively speaking) then we would be out of business. We do have an objective standard that we use to determine if software is ready for release and it has to do with the severity and quantity of bugs. We divide bugs into three severities 1, 2, and 3 with criteria for what those categories are. We will not release software with cat 1 errors, cat 2 errors have to be justified to the release team (which includes representatives from all aspects of our organization) and we fix as many cat 3 errors as possible.
Comparing our software to that developed by NASA, or air traffic control software is not a good comparison. First, you can see a difference in the prices, also there is not the same competition for NASA software that we face in the ERP business, expectation must also be higher for NASA software because of how it is going to be used, and NASA has far more resources available for developing their software than we do. Those are all factors in deciding how many bugs can exist in the software when you go to market.
It's difficult to simplify this discussion to things like greedy corporations, or poor development standards because it is much more complex than a one or two dimensional issue. There are many factors involved, but the biggest factor is market forces. Software developers are in business to make money and stay in business, the only way they can do that is to produce a product that customers will buy.
It's really quite simple, it boils down to:
Every pro/con/middle of the road statement point made thus far in this discussion thread can be put in these three categories.
Just remember this credo --> there is never time to do it right, but always time to do it again !
Rudy can correct me if I’m mistaken, but when he wrote “do it right the first time”, I suspect that he meant bug-free. The quality (fix the bugs) vs. profits considerations are, in my opinion, short-term considerations only. In the long-run, continuing to make such decisions in favor of profits is likely to actually reduce profits.
For example, if you’re in your forties like me, then you’re likely to remember that, when growing up, your parents purchased American-made cars ONLY. Try to gauge the ratio of foreign cars to American cars driven today the next time you walk through a supermarket parking lot. 8 to 1? Greater?
Why? One can try to over-complicate it, but the answer is that the Japanese auto makers have significantly higher standards for quality. The Japanese strive to build bug-free automobiles. American auto makers ask themselves, “How many bugs can we release in our products before the backlash begins to erode profits?”
(My Ford was recalled five times while I owned it and, with all the needed repairs, was more expensive to maintain than the one Honda and two Nissan’s I’ve owned combined.).
Richard’s “cat3 errors vs. cat1 errors” approach is, I’m afraid, common in our industry. That’s my complaint. In addition to being bad for business in the long-run, one can also argue that such an approach is also unethical (unless you disclose to your customers that your product is being delivered with “cat2 and cat1” errors).
Maybe I misunderstood, but I thought you and Richard were doing more than highlighting this reality regarding what many businesses settle on...I thought you were condoning it. In earlier posts, others seemed to be apologists for this reality. If so, that's where we disagree. If not, I apologize for the confusion.
Condoning it is not the right way to describe my point of view. I see it as a business decision that must be made before the software is released.
I'm saying that a business has to make a decision as to what point it is right to release software. If we were to wait until our application was bug free, we would never release software. Imagine in MS waited until SQL 2005 was bug free before it was released, we would be getting it sometime in 2015, and would we even want it at that point?
What they and I would suspect every other software company do is determine where the point of diminishing returns is met, based on many variables, and then they release the software.
You choose to purchase software based on many factors. Some people will choose to buy the 1.0 version of software, even though it may be buggy, but it really does something that they need, Windows Mobile 5.0 on my iPAQ comes to mind. Others prefer to wait until a later version comes out because what they currently have is sufficient and they don't want to fight the hassles of buggy software.
In the same way, different software companies have different criteria for releasing software. Some may decide to release software because their customers are screaming for certain functionality, so they will reduce the time spent in QA in order to get the release out and follow up with another release soon after to clean up bugs that have been found. Other companies will spend more time testing their software because their customers have a lower tolerance for buggy software. These are generalities, but it points out that there are many different market requirements for software, and in order to remain in business, the software company has to decide what is the best time for the software that they sell for it to be released.
I get it that you believe that there are legitimate business reasons for releasing software with known bugs. I'm sorry, but I'm afraid I can't agree with the arguments made to support this logic.
However, assuming I'm mistaken about the business logic ... what about the ethics of such an approach?
Even though the dba/development community is conditioned to expect bugs in early releases of software products they purchase...does that really release MS and Oracle from responsibility from delivering a finished (bug-free) product when collecting our money? Isn't there a significant cost to our employers or customers when such bugs exist (consider how much time is spent researching the causes and applying any fixes or workarounds)?
What about the general public or even a purchaser of a high-end business application who hasn't been conditioned as we have? Would management put the "cat2/cat1 error handling policy" in the product brochure or in the purchase agreement? Probably not. But would you argue that it's also "understood" by these buyers that the product will be "incomplete" when version 1.0 is delivered? If so, I'm not sure sure. I've been around a little, and that hasn't been my experience at all. My experience is that such buyers plan and expect that the product will be entirely consistent with oral and written representations made when selling the product (which is likely to exclude any mention of known bugs in the product).
Depending on statements made in the sales process, buggy software could even be illegal. Most states have "Fair Business Practice" laws that say it's against the law for businesses to make false representations to generate a sale. I'v read about software companies that have been sued and lost under such laws when, in essence, the delivered application was "buggy".
By the way...enjoying (or enjoyed) the discussion, and I apologize for any potentially abrasive sounding comments -