Re: Declarative constraints in practical terms
Date: Sat, 25 Feb 2006 12:51:02 GMT
> 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.
>>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
> 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).
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 finished. 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, and hope like hell that our design will bear the weight of expectations.
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 again.
> 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).
>>>laughing >> >>Well beyond!
> I won't ask what that would be
Being able to chuckle, even at oneself!
Rightly or not I associate for now you with MV esp. over the RM.
>>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?
> 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
Cheers, Frank. Received on Sat Feb 25 2006 - 13:51:02 CET