Another Bug Hunt

  • Sure, and I think ideally we'd all agree with Rudy. However, realistically we know what many businesses settle on, which was the point Richard was making and also what you elaborated on.

    K. Brian Kelley
    @kbriankelley

  • 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.

  • No, I don't condone it, but I do understand the realities of the situation. My mom is Japanese. I was taught to do it right or don't do it at all... lest you face a bamboo stick.

    K. Brian Kelley
    @kbriankelley

  • 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 -  

  • Chris makes some great points and I think there should be some recourse when an application doesn't do what it promises.

    However I think there is also a question of scale. Larger pieces of software that perform general functions are harder to debug and deliver bug free. The latest press on Oracle says something like 50 million lines of code that have to scanned and not many automated tools can even handle something that large. Delivering bug free software in an OS or large piece of software is hard.

    In a more specialized applicaiton, it's easier. TurboTax is a very specialized piece of software and I've rarely heard of issues in it.

  • Chris, no offense taken, I am enjoying the debate.

    Let me put my point of view in better perspective. A software company would not survive if it released software where basic functionality did not work, or even if the majority of the functionality didn't work. The market would quickly tire of this and not buy it. On the other hand, if a company that builds a complex application with many different applications interfacing with each other, that also interfaces with other applications, and has tons of functionality, if they waited until the software was bug free (which is a very high hurdle) they would never release software and would also be out of business. As I've said in the past, it is a matter of balance based on business decisions. Reality dictates that the software company has to decide at what point between these two extremes that they will release software.

    To address the ethics question, the company should disclose known issues either through release documentation or a portal that the customer has access to. Of course this is an after the purchase kind of thing but then if a sales person came into a sales call and started out by saying "Here are all the problems with our software", they would be kicked out of the competition. Plus the competitors are always there to help point out the issues with the other vendor's software, so there is some knowledge of where the known issues are.

    Would you want to wait until Excel was bug free before it was released? Do you think it was unethical to be sold Excel before it was bug free? I use Excel, but insert the name of your favorite application or operating system in its place. My answer to both of those is "no", otherwise I would not have bought the software and would still be tracking my stocks with paper and pencil.

  • Excel has bugs in it?

    I'll let you have the last word, except to say that my answer to both questions is "yes".

    Thanks!!!

Viewing 8 posts - 16 through 22 (of 22 total)

You must be logged in to reply to this topic. Login to reply