Joel Spolsky’s recent talk at Yale has some interesting bits on software quality.
He claims that über-geeks tend to focus on defining quality strictly as conforming to requirements (à la Crosby), and thus try to write automated specs for the whole program. Now, trying to write complete specs becomes the “software engineering equivalent of a perpetual motion machine”, since if your specs are complete, they describe the whole program accurately, and could be thus used to generate the actual program somehow - after all, your specs will end up being as detailed as the program itself. (btw, I love any blog entry with the terms “perpetual motion machine” and “crackpot” in it)
Naturally, the concept of “complete specs” is unrealistic and is there just for the argument’s sake (let’s just strive for “enough specs” instead.) Also, any sane definition of software quality goes beyond “literally adhering to specs.” Different stakeholders have different perspectives on quality. General product quality concepts that originate from the manufacturing industry tend to view specifications as the producer’s “path to victory.” Adhering to them should be enough to produce a high-quality product - from the manufacturer’s point of view. The value perceived by customer can be different, and consists of different attributes such as price, performance and reliability. The ultimate validation of quality is always customer satisfaction.
Although all generic product quality concepts don’t necessarily translate to software quality, there are recurrent themes on both sides: customer is king!
