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

At 02:20 PM 2/5/2004 -0500, J.B. wrote:
>>><snip>
>>
>>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.

I'm not convinced that it's all that much harder, in theory at 
least.  Right now the tools aren't there, so that is a problem.  This will 
change over time.

The next major issue is one of coupling -- take the time to reduce the 
coupling and it's much easier to refactor, ...  Many orgs have put 
themselves into a high-coupling situation and as a result are running into 
trouble.  They need to get themselves out of this situation.  Some will, 
many won't.

At conferences I like to ask people if they can roll a simple database 
refactoring, such as renaming a column, into production in less than a 
day.  About 1-2% stick up their hands.  Some of them work in new orgs with 
virtually nothing in production, so let's discount them for the sake of 
discussion.  The rest work in very large shops, have reduced coupling via 
persistence frameworks, good design, ...  These shops can be agile.  The 
point to be made is that it is possible to do, unfortunately few of us can 
do it yet.



>Now I haven't read Scott's _Agile Database Techniques_ yet. (Sorry, Scott.)

Sacrilege!  ;-)

Will you be at the Toronto Scrum/Agile Openspace this weekend?


>This is why I am not willing to conclude one way or the other on this 
>issue. Not all the results are in.

Exactly.  I only wish others, particularly those in the DM community, would 
also hold this opinion.


>  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.


Yes.  I like to say that we need to choose to succeed, but unfortunately 
many people will choose to fail.  Most people, IMHO, within the DM 
community are currently choosing to fail.

><snip>

- Scott


====================================================
Scott W. Ambler
Senior Consultant, Ronin International, Inc.
www.ronin-intl.com/company/scottAmbler.html

www.agiledata.org
www.agilemodeling.com
www.ambysoft.com
www.enterpriseunifiedprocess.info
www.modelingstyle.info
www.ronin-intl.com

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
--^----------------------------------------------------------------