Since we don't want The Business to 'shoot the engineers', we'd better be part of the solution. :) I think you've raised some great points here, as has BrowserUK. I agree with them, so the question becomes, 'how do we get not broken, sometime soonish, and reasonable cost?' I've been exposed to an Agile Programming seminar recently, and I think there's a lot to be said for some of their arguments. You have to be willing to rethink 'not broken', though, and that's hard to get an engineer to do. We want to spend lots of cycles perfecting underlying mechanisms, but Agile says 'release early, release often'. The seminar presenters suggested that there's more value to mocking up an end-to-end transaction for one use case, and getting customer buy-in on it, than in crafting a perfect back end. By using such methodology, we hand the responsibility for deciding 'good enough' back to The Business, where it belongs. As you iterate through more and more use cases, you get instant feedback on what 'not broken' means, so you end up crafting a better end-to-end-product. The Business, in turn, gets to draw the line on 'sometime soonish' and 'reasonable cost' without ending up with crap.

As you can gather, I'm sold on this concept. I have been on dozens of projects -- and run some myself -- where engineering of internals, or programming methodology, took precedence over pleasing customers and responding to their feedback. All too often, the temptation is to get lost in details because they're fun and they're safe. Unfortunately, without constant pressure to prove 'not broken', we often end up with smoothly functioning but worthless pieces when the business runs out of patience or money.

We engineers need to grow into having more business sense. It's less and less possible to be a subject matter expert in a prograamming language and have that be enough. In truth, the 'business sense' I'm talking about is not that different from 'common sense', but the sad fact is that few have that, either.

One piece of advice I heard recently was 'spend the company's money and your time as though it is your money and your time'. Ultimately, it is.

Don Wilde
"There's more than one level to any answer."

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