I am actually capable of realizing when a prediction of the future is problematic in lots of ways and in teaching others how to do so.

And all it takes is one. One ASOB who believes he can "beat the odds", and dodge the bullets of historical evidence. That he is better than all the rest.

Now check out the evidence of history.

In 2004, The Standish Group produced its 10th annual CHAOS report. An analysis of why IT projects fail. They concluded that in the period covered by the 2004 report, 34% of all projects had succeeded. And that this represented an increase of 100% in the success rate over the 10 years and 40,000 projects they had analysed.

In other words:

When asked to summarise why that (dismal) success rate had improved, the answer was: ""The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward."

In other words. Don't try to plan (predict) all possible future outcomes. Write what you know is needed, and get it out there. You will quickly find how what of what you have can be improved; and what more is actually required.

Now a word about dogma:(that [which] is proclaimed as true without proof). Example: Expenditure of time on the "maintainability of source code" saves money in the long run.

I offer not dogma, but demonstrably good advice.

Read, digest, and recognise that a common theme emerges.

The longer designs and code spend:

then the longer it will be before you find out the truth of reality. And

Think of it this way. Two men are taken to points in a field 100 yards from a flag that is their destination. They are blindfolded and spun on their heels a few times. One is given one long look to orient himself before setting off for the flag blindfolded. The other is allowed a single brief look around every 10 paces. Who makes it to the flag first?

And if you cannot see the truth in that, then the blinkers of your own legend and ego are doing you and your employers a distinct disservice.

Gambling may give you personal highs when you get it right, but when the overwhelming weight of evidence is that you will guess wrong, and when the effects of those wrong guesses on you and those around you are so dire, seeking those highs is pure selfishness.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Re^9: Legacy Code: "Dominoes = Bad" (Arrogance--) by BrowserUk
in thread Legacy Code: "Dominoes = Bad" by locked_user sundialsvc4

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.