Others have commented on "process" issues related to quality; I'd like to focus on "people" issues, the human aspect. My view is that people have a bigger impact on quality than process; that a team of low quality developers will produce a low quality product, no matter what process they use. A key quality issue then is how to attract, identify, inspire and retain quality people. (Google, for one, spend a lot of time and money on recruiting, endeavouring to hire only high quality people).

Chapter 4 "Quality - If Time Permits" of Peopleware is worth a read. Quoting this review:

Philip Crosby wrote in his book "Quality Is Free" that letting the builder set a satisfying quality standard of his own will result in a productivity gain sufficient to offset the cost of improved quality...

A policy of "Quality - If Time Permits" will assure that no quality at all sneaks into the product. Hewlett Packard is a company that makes a cult of quality, reaping high productivity due to high, builder-set quality standards. Their sense of quality identification increases job satisfaction resulting in one of the lowest turnover figures in the industry.

Power of Veto - Hitachi Software and parts of Fujitsu give project teams an effective power of veto over delivery of what they believe to be a not-yet-ready product.

Joel Spolsky tries to strike a sensible middle-ground between "sales-driven" and "developer-driven" companies by creating a Development Abstraction Layer:

You've got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales. These companies can be identified in the wild because they build version 1.0 of the software (somehow) and then completely lose interest in developing new software. Their development team is starved or nonexistent because it never occurred to anyone to build version 2.0... all that management knows how to do is drive more sales.

On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

Both of these companies can easily be wiped out by a company that's driven by programmers and organized to put programmers in the driver's seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

In reply to Re: The dangers of perfection, and why you should stick with good enough by eyepopslikeamosquito
in thread The dangers of perfection, and why you should stick with good enough by redhotpenguin

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.