Alistair,

When I was in school, we were told scary stories of the Exponential Cost
Increase monster to justify the waterfall. Turns out it was a misapplication
of valid (AFAIK) measurement on the cost of defect repair. Methodologically
speaking, that puts us back to square one.

My observation is that the cost of adding functionality follows a complex
distribution, both based on the kinds of changes made and the timing of
those changes.

Sometimes a certain kind of change can get cheaper over time. For example,
in DevCreek we had to set up a fair amount of infrastructure to collect any
data. Adding a new data source now is something many people could do. What
took hundreds of hours for experts the first time now takes a few hours for
a beginner.

Sometimes a certain kind of change gets more expensive over time. Having
been just working on a parallel JUnit runner, I can say that it's harder
with 4.5 than it would have been with 4.0. I can still see a way to approach
it incrementally, and I'm satisfied we followed a reasonable path with the
steps we took in the interim, but it is more expensive now.

Sometimes the cost of changes doesn't seem to vary much. Writing a reporter
for JUnit is no easier or harder now than it was 10 years ago.

What does this mean for development? You certainly don't want to get in the
position that something terrifically important turns out to be exhorbitantly
expensive. That, as Ron might say, would be bad. You also don't want to wait
a long time to get any results or waste effort on design that won't be used
or, worse, will get in the way.

I'm still comfortable with a strategy of aware incrementalism. If something
is terrifically important, do at least a little bit of it early. If you know
several ways of doing something, do it a way that is useful today but takes
advantage of your experience. This strategy has the advantage that it works
fairly well in practice and it works better for more experienced folks, but
unfortunately it isn't dogmatic enough for those looking for safety in
simple rules.

Regards,

Kent Beck
Three Rivers Institute

_____

From: extremeprogramming@yahoogroups.com
[mailto:extremeprogramming@yahoogroups.com] On Behalf Of aacockburn
Sent: Sunday, February 24, 2008 9:05 AM
To: extremeprogramming@yahoogroups.com
Subject: [XP] Re: How is Scrum alienating the eXtreme Programming folks?



Hi, Craig --- I hate long meaningful posts with well-balanced,
sensible questions --- It means I really have to take the time to
think through things and answer carefully ;-). That's hard on a
Yahoo! discussion post. Here's my best for now ...

> Hi Alistair,
> That statement kind of rocks my understanding - constant
> cost of change is a huge and real benefit for me. So there
> is a good chance we are misunderstanding one another.

My position is accurately stated at
http://tinyurl. <http://tinyurl.com/3yxnhr> com/3yxnhr (short for
http://www.xprogram <http://www.xprogramming.com/xpmag/cost_of_change.htm>
ming.com/xpmag/cost_of_change.htm)

Kent's most recently published view is stated in XP Explained 2nd
ed ... I don't have my copy handy, so I can't give the page number,
perhaps someone else can post that.

The potential ambiguity we have found in past discussions tend to
revolve around the different sorts of "change" - bugs v. new feature
requests, and "time", meaning within the programming team, or from
feature request / requirements gathering through deployment and
customer response. What we haven't discussed in the past is the
difference in cost as the code base grows (with respect, again, to
bugs v. new feature requests).

> How do you cope with iterative and not just incremental flow?

See http://tinyurl. <http://tinyurl.com/22mj2n> com/22mj2n (short for
http://alistair.
<http://alistair.cockburn.us/index.php/Three_cards_for_user_rights>
cockburn.us/index.php/Three_cards_for_user_rights),
and possibly
http://tinyurl. <http://tinyurl.com/33ohdb> com/33ohdb (short for
http://alistair.
<http://alistair.cockburn.us/index.php/Using_VW_staging_to_clarify_spir>
cockburn.us/index.php/Using_VW_staging_to_clarify_spir
al_development)
and anything inside of
http://tinyurl. <http://tinyurl.com/2umrmw> com/2umrmw (short for
http://alistair. <http://alistair.cockburn.us/index.php?>
cockburn.us/index.php?
Category:Increments_and_iterations)

> How do story estimates work without cost of change
> remaining (relatively) constant?

You seem to be talking about new features here... I imagine that the
estimated implementation cost of the story is relative to both the
knowledge of the team and the existing code base. Neither are static.
When you make that estimate, you will take into account both, and
could produce different answers for the same story in January
compared to July.

> Do you envisage
> saying: "well we estimate that story is a 4 day story
> if you opt to to it in iteration#1, but it is 10 day story
> if you opt to do it in iteration#40."?

There are many stories that have roughly the same implementation cost
early compared to late in the project, subject more to the changing
knowledge of the team than to the changing complexity of the code
base. This is one of the surprises to many people of incremental
development (obviously not suprising to this group here). However, I
would be surprised if the answers come out the same, because quite
often the team is much faster in later iterations.

However, I am surprised that you are estimating stories that far in
advance ... do you really do that, or was that a not-real-life
example for the sake of discussion?

> That is not how I have understood, nor
> observed Agile development to work
> - when it works well. Instead, a story that takes around
> 4 days to implement, takes around 4 days to implement
> regardless of the iteration it is implemented.

My response is subject to how you answer the previous points.

> Or am I misunderstanding you? I have observed
> first hand (relatively) constant cost change
> across multiple organisations and multiple projects
> (one spanning 4 years) using XP practices. I have
> observed first hand technical debt drown
> supposedly "Agile" projects in under 9 months.

There are too many variables here, as I hope to have indicated.
What "feels" like constant cost to programmers in the programming
team may or may not actually be constant cost when related to the
rest of the organization, the changing knowledge of the team, and the
changing complexity of the code base.

Alistair






[Non-text portions of this message have been removed]