Inspired by this node, I've been thinking a lot about design targets, and the amount they seem to move given even a relatively short project.

As seems to be (fairly) common from reading posts here, I work for a company whose ability to produce anything other than verbal, theoretical specs for programs or systems is near zero. Clearly, this leads to issues later down the line - something my boss thinks is obvious I perhaps don't, and it leads to misunderstandings like the one with the GRWBSC that lead to this node.

A perfect example of this to me is the work I'm carrying out at present - the conversion of all of the flat files to databases in the group I'm working with. At one point with one of the more fundamental files, it seemed design briefs were changing on an almost daily basis - to include attributes or exclude attributes on a whim.

Some of these changes led to fairly major recoding efforts, and I ended up writing both the DB and the scripts that process it so that new columns of data could be simply "tacked" onto the end of the database, or unwanted columns removed, and everything would still function as expected.

This, to me, isn't ideal. At one point, the database table was arranged logically, with like columns grouped together for clarity if we needed to do anything with the data manually. It was possible to see exacltly where data in a given report had come from, almost without effort. Now, it seems more of a jumble of data that just happens to produce a nice report when plugged into a pretty generic script that shoves stuff into an arbitrary order and outputs it with a header.

While I do think that generic scripts, and modules, are great, and I'm 95% certain I can use the report generation script again to generate some other report given a seemingly random set of column names and a horrible-to-look-at database table, I can't help but feel that something here is wrong. Had the spec not changed, a much less flexible script would have resulted; however it would probably have been much easier to maintain in the long run.

I can't help but feel that evolving specifications for projects lead only to code that is harder to maintain, more of a "kludge" that does the job than a carefully crafted entity.

What do people think? Is it merely taking a shortcut to try and work round changes to a design that are almost certainly going to keep happening, or is this an unaviodable balancing of people's whims against the code on disk?

I think I've rambled on for long enough ..
--Foxcub

In reply to Design Targets by Tanalis

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.