Monks,

In engineering school I was taught the 'cost, quality, time - pick two' axiom. It has been a kind guide - whenever something is wrong, I can identify some part of that axiom that was not in balance.

As a quick review, here are short descriptions of each metric:

I am not here to write about cost or time. I am here to write about quality, and in particular 'perfect' quality. To illustrate my point however, let me define some normalized metrics for cost and time (despite the fact I am not here to write about those).

Both cost and time have equivalent boundary metrics of zero and infinite. What happens when we try to define those metrics for quality?

Lets break it down a bit further. There is technical quality, and there is quality associated with meeting the business requirements.

Technical quality has some qualifiable attributes. Don't repeat yourself, make sure your code compiles, those are easy. Create coding standards is a bit more difficult, since there is more wiggle room. Trying to achieve technical perfection is insanity. You end up with a bunch of wasted time and developers who spend their time arguing over whitespace and other nuances instead of writing code which keeps everyone employed.

Business quality has some definitive attributes also, they are most often referred to as features. There is another saying I remember from engineering school - 'Shoot the engineer and ship the product'. Loosely translated, it means you don't want to try and meet all of your feature requirements. Why? Number one, your stakeholders will see that you have done this and happily hand you more to deliver, and you haven't shaken all the bugs out of what is already being shipped. Number two, you will never ship your product. Stuff always takes longer to ship than is expected, and trying to make it perfect will make it take infinitely longer.

So we don't want to ship something broken, and we don't want to ship something perfect. We want to ship something that is good enough. One way to interpret good enough is not broken, sometime soonish, and at a reasonable cost. It has taken me a while to understand this, but I think I'm getting there. Great products are never perfect, they are good enough.

In reply to 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.