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

Scott Ambler wrote:

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

I need more experience to be confident in my ability to do those things. 
  Obviously, that will only come with practice. The projects I've done 
recently have been greenfield, so I'm not getting that practice... at 
least not until they come back for more features.

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

I'm not working now, so once my book is out of the way I can start on my 
reading backlog, including your book. (I skimmed parts of it, but that's 
all so far.)

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

I don't know if I can get there in time: it starts at 10:00, the subway 
opens at 9:00 and it's about a 90-minute-to-2-hour trip. I may see 
whether I can hitch a ride.

>> 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'm different: I dove in from day one. I didn't have the baggage of "the 
way we do things" to stop me from trying to become Agile, when I first 
saw JUnit in 2000. Since then, I've always operated under the premise 
that there's a better way to do it. I don't know what it is about my 
personality that makes that easy for me, but yet it's difficult for others.

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

My preceding comment applies here, too: I don't know why people are so 
content to fail. I guess because they're still getting paid.
-- 
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
--^----------------------------------------------------------------