At this point, i think we're going to disagree more in approach than anything else, though as you have pointed out, there's some overlap where we agree in principle.

Someone once asked me (assumed?) if i design data models to directly address the application. I told him absolutely not, as that was a recipe for failure. Over time, requirements change, applications change, (but data is forever :)) and a good database design for this is absolutely terrible for that.

So, how do i design a data model? I aim for the idea and build a model around that. When i have a consistent model, it is expanded (as opposed to patched) to include the current application's data requirements. Then, when "requirements change", there is little, if any, change required to the data model. That is the benefit of designing to the idea rather than to the current application manifestation.

Applications are much more closely tied to the user experience, and are thus less likely to be able to use this approach. Though, as you put it, "with some experience have at least some idea which parts of your project are most likely to be most affected." I think it is much more than that. With experience, you can design most of your application into separate modules (or whatever fits in that environment) to allow modification. And even then, it is usually limited to the UI and not the engine that runs it.

I don't think the requirements have changed though. Requiring new reports simply means a new query need be written, IRS rules (which are known about well before they apply) simply mean another check or two is added, and data quantity should rarely affect a large project. Sure, some details were added or modified, but if that requires a redesign, someone failed to do a proper design.

In reply to Re^5: Beyond Agile: Subsidiarity as a Team and Software Design Principle by chacham
in thread Beyond Agile: Subsidiarity as a Team and Software Design Principle by einhverfr

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.