In my experience testers do a very good job on the whole. Generally speaking the QA people find a lot of stuff and give lots of feedback, but that feedback is improperly handled/managed/disseminated to the developers and so the devs either take it personally, get overwhelmed with too many bug reports, or just never hear about some things that still may be important. Ignoring the QA department is an all too familiar problem in my experience! So in general if there is a problem with a test team/deparment it's usually because they're demoralized from never being listened to by everyone else (including, often times, the programming department) and/or they're severely underpaid because their position is undervalued. After all, who really wants to pay someone good money just to tell you your software is broken?
Quite frankly I think CEO's and other management, combined with marketing, are probably to blame for most big problems that make it into public software, purely because they are the ones who make the "rush" decisions. No programmer is in his cubicle telling his boss "ship it! ship it!". Most are either perfectionists, who never want it to ship, or simple code monkeys who know they'll just have another thing to work on so it doesn't matter to them whether the current product ships today or next year.
One other problem I saw a lot was getting personally attached to a piece of software. Commercial software is ultimately intended for sale, thus it must appeal to a reasonably sized market of people to be viable. That clearly precludes the wisdom of letting a producer (for example) get emotionally invested in the product; they will surely make poor business-oriented decisions if their motivations are emotional. And a surprising number of producers, designers, etc. *do* get very emotionally and personally involved in a given product. This can be good in some ways, but if the same person is also making certain important business decisions, they are really not able to do so with a clear head.
Part of the problem too is the way most software publishers treat products and employee performance. If a producer takes on a project that is called for by market research or whatever, and they do a good job (of actually managing the production of the software - which is their job), but it ultimately has to be cancelled, it is *not* necessarily (or even likely) their fault. Their performance can be judged independently of the software's success, and it should be! The success of most software is dependent on so many factors that are completely out of any one employee's hands - especially the producer - that holding someone like that accountable for the product's success is ludicrous. It makes them worry about thier position and makes them feel guilty if it doesn't ship on time or doesn't get good sales, thus skewing their business decisions about the product in a decidely impractical and illogical way. The whole company can be seen to have failed in some sense if a product does not perform as expected, but in general no one person, or even a team of people, are solely responsible; yet this is usually how you see blame being assigned. Or at least that's been my experience. Most of these problems really extend throughout corporate America. We have an unhealthy business culture.
- Oshyan
