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

[Paul Oldfield]

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


Paul Oldfield

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com

any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[J. B. Rainsberger]

Post by Paul Oldfield
(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 :: [phone]
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[Scott Ambler]

Post by Paul Oldfield

<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.
"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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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

[J. B. Rainsberger]

Post by J. B. Rainsberger

Post by Paul Oldfield

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

Post by J. B. Rainsberger
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.

Post by J. B. Rainsberger
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.

Post by J. B. Rainsberger
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.
"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 :: [phone]
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: gcma-***@gmane.org

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com

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