The OP seems to be on the edge of a particular issue that really rips my nighty, that is non-compliance. Some work environments have standards, and some of these are loose ad-hoc in-house standards that they've worked out themselves over the years and pretty much held by oral tradition, others are terribly strict standards imposed by outside agencies and take up several dozen shelf-inches of documentation, and of course there are a vast array of in-betweens.

There is a tendency by some (usually those new to the environment and have 'more experience' in the field of work, just not with the standard) who pull the "It works. Bugger the standard. I'm done" routine, and often because it works, and saves time, this is usually ignored. This seems to be fine in the short term. Then change happens; staff turn over, something breaks, a system begins to behave strangely, you're audited by your standards compliance agency, or worst of all you're audited by the government agency who makes you work to that standard.

This is where non-compliance blows out whatever perceived savings that the short-term thinking that "It's good enough dammit" argument leads to. Several hundred hours of unchargable work1 to patch up whatever hole is in your project. Often workplace standards are there for a reason, sometimes it's for a 1 in a million risk, but sometimes this is unacceptable. The thing to consider here is that the properly compliant work barely gets a second glance, and auditors are canny bastards who instinctively home in on the project with the most spectacular compliance issues.

I suppose what I'm describing is the other side of this argument: When is 'good enough' not good enough. I mean, is 'it works' good enough for Air Traffic Control, Medical Systems, Utility Networks, Food and Drug Testing, Your Bank's Web site, or Space Flight Control Systems?

1In a rather special incident our Director had to counter sign several hundred data record documents (and initial and date the corrections) and have them countersigned by our QA, the clients QA, and the government representative, because a particular employee refused to sign them as a waste of time. It had to be the Director because all the other members of that project were no longer employed by the company. Not a programming example, but it has analogies. In this case failure to patch the problem would have lead to our company and all it's employees open to charges of fraud. Nice.

In reply to Re: The dangers of perfection, and why you should stick with good enough by Bloodrage
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.