Re: Declarative constraints in practical terms
Date: 25 Feb 2006 06:04:18 -0800
Frank Hamersley wrote:
> dawn wrote:
> > Frank Hamersley wrote:
> >>dawn wrote:
> >>>Frank Hamersley wrote:
> >>>>dawn wrote:
> >>>>>Frank Hamersley wrote:
> >>>>>>dawn wrote:
> >>>>>>>Brian Selzer wrote:
> >>>I tend to like complete high level design and iterative phases in the
> >>>detail design, but each project has a different set of risks, tools,
> >>>etc. I haven't yet seen a project where the design is finalized, as in
> >>>no changes made whatsoever to the design after this point, before
> >>>coding starts. I have seen projects where it was said that the design
> >>>was final, however.
> >>Not quite sure what your point is here - can you please elaborate - but
> >>not too much, even though I'm sure our readers are already somewhat
> >>inured? :-)
> > You didn't keep the question or comment I was replying to here, so,
> > nope, I don't know what my point was. Sorry, probably just hormone
> > fluxuations knocking my brain out.
> It was about the last 2 sentences. I assumed it was suggesting the
> "final" call was premature as evidenced by later changes required to
> make it workable!
> >>AFAIK basically the agile methodology is much like a circular form of
> >>the waterfall method, just with a shorter radius and more iterations in
> >>a given time period and definitely more than 1 iteration before
> >>delivery. I didn't think it meant reordering of process steps per se.
> > One of the key concepts of agile methologies such as XP is that you
> > only design and code what meets the requirements (in the form of user
> > stories) for this iteration and don't put in "for future use" design or
> > functionality. it is a "don't think past your nose" approach. There
> > is some evidence this is helpful for stemming problems like
> > design-everything-for-all-time-before-you-have-anything-to-show-for-your-work
> > efforts. When you get to a new iteration where the requirements prompt
> > you to drastically change your design from what you have so far, you
> > make that design change then (refactoring your code and all).
> And stick out your cap for funding to do the unforeseen (or ignored) rework!
Yes. A benefit is that you don't end up coding a lot of maybe-someday pieces of code anticipating extensions in future phases. It is hard to maintain code like that. But I think it is important to design foundations (why would I use that term?!) very well from the start so you don't end up having to pour the basement after the walls are up.
> This concept (short-termism to coin a phrase) is an over reaction to the
> failed kitchen sink and all projects that never ever seem to get
> It is a very 21C trend - I want it and I want it now! The
> agile goal is to keep the users interest by continuously serving up
> small bits of fluff,
I disagree with that. I think the goals of agile methodologies are admirable. Huge projects that never deliver anything have been a significant problem in our industry. Getting as quickly as feasible to a build of the software and doing regular (e.g. daily) builds and tests from that point has been a good contribution. Eliminating analysis and design in order to get to that first build has not been a good contribution.
> and hope like hell that our design will bear the
> weight of expectations.
Most practitioners would say that if you are meticulous about refactoring your code with every new requirement, you can keep moving forward and add in anything required by the user. I think this can work for some smaller projects. If you can start from where you are an precisely add in code to meet the next iteration of functional requirements, then you are setting yourself up to do that for the long haul with the software. It is a way to build agility into the culture. But I wouldn't want the final iterations prior to delivery to finally address security, reliability, scalability... These should be designed into the solution from the start.
> To drag out the dreaded "foundations" metaphor - lets hope after
> building a single story house on some appropriate foundations, that our
> 20 floor skyscraper will not collapse because of dodgy foundations. It
> smells like those French cathedrals and their flying buttresses all over
> > It is important to decouple the front and back. This approach does
> > nothing to force you out of the RM, I don't think, although I've never
> > used it with the RM (nor with IMS, for that matter).
> It would be achievable, and perhaps interesting to try!
Life is short, however.
> >>However I will continue my quest to get you to keep not only the baby,
> >>but the bath and the water (for recycling of course).
> > Yes, it was a shame when that list attribute baby was thrown out with
> > the RM, eh?
> Not in my book - I like my bricks single and clean, not already cemented
> together in bunches that might or might not serve my need.
We are each anal retentive in our own ways then. If I were /only/
working on the database side of software, perhaps it would be a nice
way to shove complexity to others. I like the crisp, clean approach of
being able to model a list as a list, for example.
> > I was thinking that a lot of small projects don't have much problem
> > using 1NF. They typically just restrict the collected data to single
> > values as is the case with a ton of web page forms.
> >>I understand your perspective, and admire your preparedness to go
> >>outside - I just want ensure you to put your helmet on _before_ you open
> >>the hatch!
> > thanks for the tip
> No problem Major Tom(asina)! :-)
I've taken my protein pills. Oh, and planet earth is blue. --dawn Received on Sat Feb 25 2006 - 15:04:18 CET