Some readers attributed the problem to the Microsoft school of software development. "When I was a corporate programmer in the 80s, we wouldn't dare deliver code with bugs," wrote one reader. "And if one was found, we'd be up overnight to fix it. Bad code was a career-limiting move. But as the business got used to paying less on PC software, they'd question the costs we were quoting. I started cutting out huge chunks of time that would've been spent reviewing requirements, testing, and debugging. I'd tell clients that I was using the 'Microsoft Methodology' -- which meant that we delivered a version of the product that wasn't fully debugged, but the user would get it weeks or months sooner and cheaper, and they would help find bugs to be fixed in the next release. And they'd always nod enthusiastically and agree that that was a good model because that's how Excel/Word/Project -- fill in your favorite MS product -- worked."

But software bugs are hardly limited to Microsoft or PC products. "The fact of the matter is, people do not have a decent "Why would anyone build a decent operating system or application when it is evident people will spend hundreds of dollars for something that doesn't work the way it should?" another reader wrote. "This is not to pick on Microsoft. This can be said for most accounting packages, and probably most MRP packages. What is interesting is I don't think this can be said for TECHNICAL software, such as CAD. The market rules: If people are willing to spend hundreds of dollars for crummy software that doesn't work, why spend the money to write good software?"

Some readers felt that software developers simply aren't capable of keeping up with the demands of a more complex business. "I'm not sure if software is getting buggier so much as the environment in which software operates is getting more and more complex," wrote one reader. "You no longer just have to worry about your own software; you also have to worry about lots of operating system variants, hardware, memory-resident utilities, libraries, environment paths, memory architectures, RAID arrays, etc., etc., etc. And especially with stuff like copy protection that is designed to operate 'on the edge,' so to speak, the infinite variety of supposedly compatible computers means there just so much room for things to go WRONG. Personally, as a software professional, I feel the complexity of the environment we have to deal with now exceeds by far what I was encountering ten or fifteen years ago. If I'd known it was going to get this bad, I never would have gotten into this profession."

And bugs wouldn't be such a problem if software support were better. "The state of the art in software design quality control has not kept up with the pace of increased complexity," wrote another reader. "Brute force debugging by herds of QC staff is not sufficient. Thus, bugs proliferate. On the other hand the bugs in prior generations of software were dealt with more effectively. Simply stated, the pathetic decline in the quality of software support is, in my view, the major culprit. The number or severity of bugs is not the issue. Without a sufficient number of flyswatters, the infestations will remain intolerable!"

Many readers feel the bean counters that run most software companies just won't pay for adequate testing before the product ships of bug fixing afterwards. "I think the problem is that there's no clear payback for testing dollars and no clear measurement of what is enough testing," wrote one reader. "Managers save money by cutting back on testing -- by the time the effect shows up in poor sales for the next version they've moved on and aren't hurt by it, it's someone else's problem. Furthermore, the support people seem to be trained to ignore bugs so there isn't even any direct feedback showing how badly they messed up."

And some readers felt the offshoring of software development is a critical factor. "The real issue you should be highlighting is not the capability of quality control departments but the software development talent," another reader wrote. "Could there be a connection to the amount of relatively recent offshore development, and layoff of older/senior/experienced developers onshore? You think? It's not to say that offshore or lower cost staff are naff per se, but anything that puts a large geographic and/or time distance between the company and its designers is going to make quality harder to achieve, especially if the time to market constraints remain the same. Manufacturing has been exported to lower cost locals for years with success, but how often is the whole hardware design team exported too successfully?"

Where do you think the blame for poor-quality software lies? Post your comments below or write me at Foster@gripe2ed.com.