Design Targets

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

Comment on Design Targets

Replies are listed 'Best First'.
Re: Design Targets by BrowserUk (Patriarch) on Oct 17, 2002 at 08:26 UTC
This sounds all to familiar to me. Been there, done that way too many times. Unfortunately, I've also worked on projects where extensive and comprehensive analysis and design was done; comprehensive (and usually huge) specification documents were drawn up, test plans written and projects plans laid out. And still the design had to change, the code be re-written etc etc. That's why (for me) the most exciting (and don't use that word often or lightly) thing I have seen, and the only new design 'philosophy'--'paradigm', 'methodology', call it what you will--that has registered anywhere above "Oh god, here where go again" in the last 20 years, is Extreme Programming. Much of it is in part, familiar territory for me in as much as I have, through choice or dictum, used one or more of the XP techniques on one or another project down the years. I'd even go as far as saying that I had realised the benefits of some of them a long time since, especially small teams/pairs, iterative (RAD) development, even the practice of defining the test criteria and writing the testcases before the code, but the simplicity and clarity with which the XP picture brings all of this and many other good practices (not ideas) into a single, operable and cohesive whole is--I pondered for at least 5 minutes for the right adjective here--elegantly concise and simple. I guess I should have said extreme, but that has connotations that I don't think sit well with management types. 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. The upshot is, that if the project plan is designed around the concept of continuous improvement, refactoring (latest buzzword), getting the simplest possible function set working and testing correctly as early in the project as possible, and then extend and refine functionality as you go, the process of incorporating evolutions in, and backing them out becomes a simple part of the daily process. What I used to call, 'suck it and see' programming before they invented fancy buzzwords to describe the process. Of course, this is all just so much hot air if your unlucky enough to be in one of those shops where dogma and rhetorical programming practices are the norm. Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!	[reply] [d/l]
Re: Design Targets by ignatz (Vicar) on Oct 17, 2002 at 08:55 UTC
Designing for flexibility is a key skill as a programmer. After years of playing chess and reading civil way histories and despite years of psychotherapy I tend to see software design as a battle and we're on defense. Sure, it's easy to build defenses that can withstand a head on assault, but usually that wave is just a ruse that the enemy has devised as a distraction. It's just a matter of time before they let loose with their flanking maneuvers and if you're unprepared they'll snap your forces in two like an old toothpick. A good defense means building structures that meet the layout of the geography yet flexible enough to withstand what attacks the enemy might devise. And, believe you me, I'm ready... oh yes... me and Mister Felps (waves little stuffed pink bunny) are just waiting for them, isn't that right Mister Felps.... they come anywhere near this cubicle and we shall UNLEASH HELL!!! ()-() \"/ `	[reply]
Re: Design Targets by bilfurd (Hermit) on Oct 18, 2002 at 07:50 UTC
I don't know if Mister Felps would agree with me, but I recommend strengthening your data structure. I cannot begin to tell you how much code I've seen written to compensate for a bad data structure. Once it has been in use for a few months, a bad data structure can evolve into something really nasty. Kind of like that take-out somebody left in the office fridge -- trying to clean it up just makes you gag...	[reply]
Re: Design Targets by Anonymous Monk on Feb 21, 2011 at 04:33 UTC
This needs some kind of revision, isn't it folks ?	[reply]