On the other hand, look at the recent new release of Nero 7 by Ahead software, a medium-sized software company. Big enough that their program is sold by B&M's such as Best Buy; not big enough that everybody knows what the product is (CD/DVD burning suite with A/V editing tools bundled). It's been an incredibly buggy release, with tons of angry and frustrated customers, and a lot of poor support (most likely because the support dept. is overloaded by the sheer volume of users with issues). I'm sure they're working hard to fix the issues, but it sounds like it stems from the number one problem with apps like these: pressure on the developers from the beancounters/sales folks to release a product before its ready for prime-time, and that middle-level products often don't have the resources to test the diverse amount of hardware that a big developer does.

Where have you been, on another planet? ;-)  The adequate (never large) SQA depts all but disappeared in the mid- to late-80's.  But you can't "test in" quality, it has to be developed with a quality focus in the first place.  Testing can veto release, *if* the bugs are found, but only if they can get their voice heard over project managers/bean counters/marketing depts.

The real issue you should be highlighting is not the capability of "quality control (sic) departments" but the software development talent.

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, esp. 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?  This is the corrollary to software, outsourcing your detailed product design.  And without even a rigorous definition language a la mechanical drawings, schematics and document control depts.

• WordPerfect 5.1 for DOS--first version that came out in 1990 was worthless; bugfixes were still created as late as '95 (5.1+ for DOS)
• Windows 3.0--couldn't load images greater than 64K into memory (solved with 3.0a and 3.1), among its other proglems
• WordPerfect 5.1 for Windows--totally unstable piece of crap that needed a whole new release to save-face (5.2)
• MS-DOS 6.0 & Doublespace--not only were many of the Microsoft rebranded apps buggy, Doublespace was a nightmare to which Microsoft gave away MS-DOS 6.2 to save-face; then Microsoft got sued by Stac for patent infringement with Stacker and had to have offer MS-DOS without compression (6.21) and then with a new compression scheme called Drivespace (6.22)
• WordPerfect 6.0 for DOS--useless until at least 6.0b
• Word for Windows 6.0--Microsoft was releasing bugfixes up to 6.0c
• WordPerfect 6.0 for Windows--incredibly buggy and required a 7 disk 6.0a patch (which was pathetic given that 6.0 needed 12 disks to install!)
• Windows 95 with Plus--caused recalculation errors in Excel 95
• SoftRAM 95--lawsuit over the fact that the program did nothing
• Netscape 2.0--first version to include Java & Javascript; all versions thru 2.02 were unstable and Netscape had to release 3.0 to save-face
• Windows 95B--USB support existed which usually brought down the OS if used; Windows 98 had to be used to resolve
• Word 97--couldn't save files in Word 6.0/95 format

Which means the only way to go now is up.

May not be new to people here but this article confirmed my suspicion that the problem is certainly not accidental or random but, at least in some cases, pretty much built into the system itself, unfortunate as that sounds.

Of course it's not just software: I think it was David Halberstam who wrote a fabulous book some years back -- think it was The Reckoning -- that showed how the shift in management priorities over the decades from production to financial has lowered quality throughout. He talked about the auto industry here but the concepts were more or less universal.

The second issue was with importing.  I started the new return by importing my previous year's return, which included a schedule A.  When I entered my 1099G for State income tax refund, though, the program refused to treat it as taxable income because I had not itemized the previous year!

The response to my attempt to notify them of these errors was totally unrelated to the problem.  It took 3 or 4 emails till I got someone who could even come close to understanding what I was saying.

Then, after I e-filed my return, the program refused to acknowledge that I had done so when I asked it to check the status, even though when I went back through the efile questions all the answers were there.  

One thing I can certainly say about "Bugs" is that most of them are not noticed until the software has been deployed for a while.  I run extensive checks on the code, including input tests, code read-through, module level testing and finally end-to-end tests of invalid input to check that the error checking works.

After all these reasonable checks, I will deploy the product and have someone using it for a few days only to send me a report that some feature I tested doesn't do what they expected.  After checking I find that they are passing values I didn't plan for, or data is longer than I expected, or even better, the value calculated is being modified by some other part of the program which should not be doing anything with the results.

Some times it is flawed logic, or a lack of understanding of what I did a few months or years ago when I started to write the program.  Other times it is a transcription error, where the value or function is correct, but invalid for the situation.  All-in-all, most of my problems are related to the "Coder" and the "Software Definition" and not the level of complexity of the project, or the operating environment.

Once these types of "Bugs" have been eliminated, I have run into a few other very hard to handle problems. First, there is the timing issue when running code affecting data on a remote server.  I find that at times the process "Times-out" and I get corrupted inputs in my database.  Other times the network "Times-out" and I lose my database connectivity.  Finally, the speed hit I take when running across a network with one or two other people connected, as opposed to running on my local workstation/PC is so significantly bad, that I find I cannot reasonably expect to get any work done until after hours.

The state of the industry is where it is for a number of reasons.  Most of which were discussed already by people who are probably tied very closely into the software industry.  The only problem I see which seems to be the most significant problem, is that as programs grow larger and larger, they begin to use features which are not necessarily understood by the programmers - since they did not write them - and the results can be unpredictable.  More than that, when a program uses a feature of the operating system, or of some other part of the operating system, it becomes less and less robust and eventually can become unstable or non-functional, simply because it is not encapsulated within the program itself.

My favorite gripe is programs which replace parts of the operating system so that they "Work for all configurations" or which modify the components of the operating system to "work cleanly".  This was more prevelant with development programs like Visual Basic 4.0/5.0 where certain files would be over-written in the /system folder, like VBX or OCX files, and existing programs would crash because the addressing of the functions contained within the VBX or OCX files had changed due to the new program's "Customizations".

I also should not fail to remind people of "DLL HELL" which everyone who had a Windows 98 or NT machine had to deal with.  Just go on and install that program, and it puts a '98 DLL in - overwriting your 64 Bit NT dll and crashing your graphics sub-system or your file sub-system.