My father in law is a construction engineer. Once I told him that software projects often fail, take to long and/or are way over budget, and that I wished that we used the established engineering practises from his field. He looked at me with very wide eyes and asked me if I seriously believed that "his" embankment dam projects fared any better.

Note that those projects also have significant maintenance costs, often due to less-than-perfect upfront planning and execution.

A commonality between software and civil engineering projects is that planning ahead works well if and only if you know the environment, the problem domain and the requirement very well, and none of them are changing.

I often read programming job ads, and it seems to me that most of them focus greatly on the tools (you need to have 5 years of experience in $language and $framework and $webserver and HTML and CSS and Javascript and 20 years of scrum experience), but mostly ignore the problem domain. I think that is one of the big shortcomings of current "best practices" in the software business.

Explorations into unknown regimes are best done from the bottom up. You can best see that in long-term research projects that first explore the underlying effects before trying to build any devices from them. And any project outside of your domain knowledge is as new to you as a research project is to the scientists investigating it.

So, if you are a software architect who has already built five web browsers, and are now charged building the sixth, taking the waterfall approach might make some sense.

If you have built a browser, a word processor and a web server, building a new compiler is still a research project to you. You could chose your methodolgy accordingly.

Perl 6 - the future is here, just unevenly distributed

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