And you can refactor it later if it really builds up to something big.

Oh, you've hit a pet peeve of mine. I am working at a company that had revenues of roughly $65 million dollars last year. We have grown revenue an average of 72% year on year for the past 7 years. We are looking at a 125% increase in revenue this year, assuming that one third of the projected contracts are actually signed. It could be as high as 200%. This means that 7 years ago, we had revenues of 1.5 million dollars. In 8 years, we have increased 100x. Our IT staff has gone from 2 people to 22 people. Our total staff has gone from 20 to 250.

What does this have to do with anything, you might ask. It's very simple - our systems have grown incrementally with an extremely short feedback loop. And, they are best described as cancers or weeds. The system is a mess and it is more dangerous to modify it than it is to throw out and start over from scratch. Except, refactoring now would cost $500,000 and take a year. Ooops!

Remember - incremental design does not in any way imply successful design. In fact, it almost never does. You end up traversing the twisty maze of:

You are right - a hallmark of most successful modern applications, proprietary software aside, tends to be incremental development. It is a necessary condition, but it most certainly is not a sufficient condition. There are at least three other conditions I can think of that are required that incremental development doesn't even begin to touch.

Give me a project with those three conditions and I'll be happy to work top-down. Give me a project whose only bright point is incremental development and I'll quit in less than 3 months.

Another personal story - I worked at an e-commerce firm which had a continuously incremental development cycle.

Yet, we had no test suites, no design, no peer review ... no nothing. When I asked about design, my director said "Do it on your own time." But, we had incremental development, so we should've been ok, right?

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

In reply to Re^5: Spreadsheets, HTTP::Recorder and interactivity by dragonchild
in thread Spreadsheets, HTTP::Recorder and interactivity by zby

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.