I work in a contract environment, and it's in our mandate to avoid feature creep. Enhancements have to be derived from the requirements and design that the customer bought off on, or we require more money. Bugs that interfere with our commitments to the customer, on the other hand, are handled with extreme prejudice.
MS is in a different situation really because they have no contractual obligations. Nobody is really pushing against their products for quality, so their upgrades are driven by marketability or something.
The irony is that quality is the best marketing. The product that aims at marketability at the expense of quality will achieve neither, the product that aims at quality at the expense of marketing will achieve both.
I work in a contract environment, and it's in our mandate to avoid feature creep. Enhancements have to be derived from the requirements and design that the customer bought off on, or we require more money. Bugs that interfere with our commitments to the customer, on the other hand, are handled with extreme prejudice.
My employer (who works in a highly regulated industry) works the same way. If a core product must be modified, we issue a change control memo. The items in the memo either have to be tied to bugs in our bug-base or, in the case of enhancements, a specification.
Because of the high volume of paperwork that surrounds software releases (specifications, documentation, test matrices, test reports), enhancements are typically put into a stack until there are enough to justify the load of paperwork that must accompany such a release. Bug fixes still require paperwork, but specs don't need to be written, only test reports.
My sympathies. We don't have as much overhead involved, but around integration time, it gets a lot like you're describing. We get away with a lot of common sense at other times.
More often, our enhancements get rolled into a new contract. If they are peripheral enough, we might not even do requirements for the new contract. Just using the old change requests is as specific as it gets.
It's actually not as bad as it sounds. Devs produce only a small amount of documentation (including unit test reports)--it's the product manager and QC department that really have the burden of documentation. It's nice having a well-defined set of requirements, and because of the overhead of updating documentation, scope creep is kept to a minimum.
>The irony is that quality is the best marketing. The product that aims at marketability at the expense of quality will achieve neither, the product that aims at quality at the expense of marketing will achieve both.
It'd be nice if it'd be true. But look no further than the example at hand and its relatives.
MS is in a different situation really because they have no contractual obligations. Nobody is really pushing against their products for quality, so their upgrades are driven by marketability or something.
The irony is that quality is the best marketing. The product that aims at marketability at the expense of quality will achieve neither, the product that aims at quality at the expense of marketing will achieve both.