Re: Declarative constraints in practical terms
Date: Sun, 26 Feb 2006 10:35:07 GMT
Message-ID: <vvfMf.16585$yK1.6128_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote: >>>Frank Hamersley wrote: >>>>dawn wrote: >>>>>Frank Hamersley wrote: >>>>>>dawn wrote: >>>>>>>Frank Hamersley wrote: >>>>>>>>dawn wrote: >>>>>>>>>Brian Selzer wrote:
[..]
>>>>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.
Why code it then, why not just do enough design work to ensure it will integrate simply?
> 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.
Yep - its good to avoid that one.
>>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.
>
> Yes. I call it the "let's not think past our noses" approach. I'm
> equally unhappy with analysis paralysis or designing every last details
> for all phases prior to laying any code approach.
Both are tails on a bell curve distribution IMO.
>>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.
All methodologies goals are admirable. I admit I was being a bit facetious about the fluff, although I suspect sometimes DBD2 (Dan Bricklins Demo II) gets a run to keep the wolves at bay.
> Huge projects that never deliver anything have been a
> significant problem in our industry.
And so are small quickly prototyped projects that promise everything and then fail miserably when scaled.
> 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.
Agreed - my beef is (as always) if the talent isn't there then neither methodology is going to guarantee a result.
>>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.
Yes - it seems to work well in the OS (Open Source) arena - not sure if commercial operations can quite stand the non-determinate delivery process yet. Like "yes madam, we haven't paid you any interest yet, but be assured when our new system gets finished, we will work out how much we owe and pay it all then" will really secure a customer base, not.
> 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.
Yes - definitely.
[..]
>>>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.
And I'm sure there is some cosmologists who would like their vb objects to inherit the universe - where does it stop?
BTW what is so interesting about a list that can't be represented by a relation of scalars?
Cheers, Frank. Received on Sun Feb 26 2006 - 11:35:07 CET