Re: DM speculative design; was: Re: [AM] Unfounded assertion

Paul Oldfield wrote:

> (responding to J.B.)
> 
> 
>>>(Dagna)
>>>But we can (or, at least, I 
>>>can, and I don't think I am that unusual!) work out that if a field is 
>>>made up of compound data (like initials + surname, or quantity 
>>>multiplied by price to give net value), then someone is going to 
>>>look at  it and want to get at the elements. (The price per unit.)
>>
>>(J.B.)
>>On this the Agile community and those generally outside the
>>Agile community disagree and will likely always disagree. One
>>of the fundamental differences between Agile practitioners and
>>everyone else /seems to be/ that Agile practitioners treat
>>speculative design as a liability, whereas others treat
>>speculative design as an asset.
> 
> 
> The important thing to know is that both these viewpoints are
> rules of thumb based on the relative costs and benefits of
> speculative design.  We reach different conclusions because
> our approaches give different breakdowns of cost, thus
> different cost-benefit balances.  This is important because
> the rule of thumb will not necessarily apply in different
> conditions.  Of course, this last observation is also important,
> because it implies that if we want the rule of thumb to apply,
> we need to change the conditions in which we work.
> 
> Agile approaches understand the benefit of not having to do
> speculative design, and have ensured the cost of deferring
> design until it is *not* speculative is reasonably low - in an
> agile 3GL programming environment.  We have not done that 
> yet for a Data Management environment.

Agreed. I keep coming back to Ward Cunningham's talk at XP/Agile 
Universe 2003. He mentioned that for XP to be successful -- and I think 
we can extend the thought to other Agile approaches -- both the 
organization and the material have to be right. In this case, the 
material may be wrong. It may not be sufficiently easy to "work the 
database" the way we can "work the program". This may make an Agile 
approach more difficult than it's worth.

Now I haven't read Scott's _Agile Database Techniques_ yet. (Sorry, 
Scott.) This is why I am not willing to conclude one way or the other on 
this issue. Not all the results are in. I have been successful with 
taking an Agile approach to databases in the past two or three years, 
but that's a small sample. I haven't had to do everything needed in a 
typical Data Management environment yet. Perhaps someday soon I'll be 
able to conclude for myself.

That said, it is important to keep in mind what you have written here:

"if we want the rule of thumb to apply, we need to change the conditions 
in which we work."

As Ron Jeffries is fond of saying, changing those conditions is usually 
easier than we think it is.
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------