From Calvin and Hobbes:

CALVIN: How do they know the load limit on bridges, Dad?
DAD: They drive bigger and bigger trucks over the bridge until it breaks. Then they weigh the last truck and rebuild the bridge.

For what it's worth, I have built a (small) house in the "release early and often" sort of fashion, without any blueprint beyond some rough outlines on paper. Obviously there are disadvantages: sooner or later you'll realize you forgot to leave room for such-and-such, and have to adjust or redo something to compensate. You could end up spending a day breaking up concrete with a jackhammer because you forgot to put in the drain for your shower.

But there are advantages too. It's hard to know just what a room or an overhang is going to look like until you see it for real; blueprint drawings or even CAD mockups just aren't the same. If you're figuring it out as you go along -- and building with that in mind -- it can be easier to change your mind and make adjustments along the way when you have new or different ideas. You're not constrained to a blueprint because you don't have one.

There has to be a healthy balance, of course, between rigid pre-planning and unplanned chaos. But when it comes to software, I think there are valid reasons to lean more toward the chaotic end. It's a lot easier and cheaper to tear down a program and start over than it is to tear down a house and start over. And release-early-and-often gives you much faster feedback than you can get by doing your own testing. (How many times have you found a bug in a piece of commercial software and thought, "How could they possibly miss that?" That was a regular thing in C64 games back in the 80s, even from software houses with large teams of testers.) Faster release cycles mean faster development.

The other reason I tend to lean toward try-and-fix is that it's just not possible to plan perfectly. No matter how many planning meetings you have, how much documentation you write up in advance, how many tests you prepare, something is going to go wrong and have to be fixed. So no matter how much you plan, you still need the flexibility to respond to issues that come up. If you have that flexibility, why not use it as much as possible?

Aaron B.
Available for small or large Perl jobs; see my home node.

In reply to Re: OpEd: Programming is not Team Sports by aaron_baugher
in thread OpEd: Programming is not Team Sports 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.