File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Cost of Changes Flattens with Time? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Cost of Changes Flattens with Time?" Watch "Cost of Changes Flattens with Time?" New topic
Author

Cost of Changes Flattens with Time?

Siegfried Heintze
Ranch Hand

Joined: Aug 11, 2000
Posts: 381
Kent Beck in his book "Extreme Programming Explained" says the cost of changes to a software project flattens out with time in contrast with Boehm whose says the cost rises sharply with time.
I really was not impressed with Kent's defense of this hypothesis. First he gives an example of a minor design flaw and then says the cost should go down because advances like object-orientation should make the cost flatten with time.
Pete McBreen in his books "Questioning XP" claims to address this issue but in fact claims that there will be fewer design flaws because of the test first approach of XP. (Oh -- Pete does mention that the cost of changes will flatten because Boehm in 1981 claims that the smaller the team, the less dramatic the rise. Boehm says the cost of change is 100:1 for a large time but only 4:1 for a small team. This is another week argument on Pete's behalf).
Why should I believe the cost of design flaws goes down with time? Why should I believe OO contributes to the flattening of the cost curve?
Why should I believe the test first approach minimizes design flaws? It seems there are a lot of tests that cannot be run immediately.
Thanks,
Sieg
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I think it's not OO in particular which contributes to this effect. Two of the important parts of XP are automated testing and continual refactoring. In my mind these are the two main factors in reducing the cost of change curve.
By providing an automated test "scaffolding" which grows with the software we can ensure that no fault will inadvertently reappear, and no feature will inadvertently get lost. This in turn allows bold refactoring to be performed, safe in the knowledge that we won't break anything (at least without knowing it straight away, and being able to roll back a few hours to a known working version). Aggressive, continuous, refactoring really can help to reduce the cost of change: Removing duplication reduces the amount of places things need to be changed, and reduces the likelihood of missing something, clarifying the division of responsibilities helps make it quicker to find what and where to make a change. Recognizing patterns and gethering code into frameworks allows the code to be more prepared for unexpected changes.
Compare this with a non-automatic-tested, non-continually-refactored system. In this case, as the software grows it gets more complicated and less understandable. Unknown duplication and mysterious code greatly increases the time taken to find what to change and the chance of unexpected "bugs" followed by the associated long debugging cycles. More time has to be spent on documentation in an attempt to prevent future maintainers from reintroducing old faults or breaking old features. And sometimes it gets so bad that it has to be thrown away and completely reengineered at huge cost and risk.
The above is, of course, just my opinion, but I have seen these effects in projects I have worked on. I can come back to a tested and refactored project six months later and it still makes sense!


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Siegfried Heintze:
I really was not impressed with Kent's defense of this hypothesis.

I am with you here. But that doesn't mean that the hypothesis has to be wrong, of course...
(Oh -- Pete does mention that the cost of changes will flatten because Boehm in 1981 claims that the smaller the team, the less dramatic the rise. Boehm says the cost of change is 100:1 for a large time but only 4:1 for a small team. This is another week argument on Pete's behalf).

Why is this a weak argument???
Why should I believe the cost of design flaws goes down with time?

You shouldn't - nobody said *that*. Flatten the curve doesn't mean that costs go down, just that costs don't rise as drastically as Boehm showed.
Why should I believe OO contributes to the flattening of the cost curve?

I think one of the contributing assumptions of the Boehm curve is that late changes in design will affect many parts of the design. As OOP is a technique to decouple designs, it might contribute to reduce that effect.
Why should I believe the test first approach minimizes design flaws?

Because test first development also reduces coupling.
Additionally, it reduces the cost of design changes because of the resulting high test coverage, making relentless refactoring possible.
It seems there are a lot of tests that cannot be run immediately.

I don't understand this statement - test-first tests will pass in terms of minutes after written, by definition...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Siegfried Heintze
Ranch Hand

Joined: Aug 11, 2000
Posts: 381
> I think it's not OO in particular which contributes to this
> effect. Two of the important parts of XP are automated testing and
> continual refactoring. In my mind these are the two main factors in
> reducing the cost of change curve.
So what is the cost Pete is talking about? The graphic from Boehm
talks about the cost of fixing defects (or changes - I cannot
remember). But I see you and Pete are talking about the cost of
development because you are talking about testing early to avoid bugs.
And how is this different from UP where there is a lot of testing too?
> > (Oh -- Pete does mention that the cost of changes will flatten because
> > Boehm in 1981 claims that the smaller the team, the less dramatic the
> > rise. Boehm says the cost of change is 100:1 for a large team but only
> > 4:1 for a small team. This is another week argument on Pete's behalf).
>
> Why is this a weak argument???
>
4:1 is still extremely high. Is Pete saying 4:1 is acceptable? Where
is the evidence that allows Kent to say the curve becomes
asymptotically horizontal instead of asymptotically vertical like
Boehm says? The shape of the curve is very important.
> I think one of the contributing assumptions of the Boehm curve is that
> late changes in design will affect many parts of the design. As OOP is
> a technique to decouple designs, it might contribute to reduce that
> effect.
Hmmm... that assumes you are not using a relational database
(RDB). These beasts are not OO.
Actually, OO could be a good argument! However, it is a poor argument
because I don't believe most programmers understand decoupling as it
relates to OO. Here is an example:
When you create a modeless dialog box, the parent (perhaps the model
or the view object) must contain a pointer to the dialog (because some
function is going to create the dialog and return without invoking the
destructor). However, the dialog, because it is modeless, must contain
a pointer to the parent which makes it tightly coupled. One easy
resolution, is to use multiple implementation inheritance to add a new
special ancestor to the parent that the modeless dialog can point
to. Java and C# programmers don't have implementation inheritance and
many C++ programmers are to scared to use it. If XP programmers are
going to do the simplist thing that could possibly work --- you can
forget decoupling!
> > It seems there are a lot of tests that cannot be run immediately.
> >
> I don't understand this statement - test-first tests will pass
> in terms of minutes after written, by definition...
I agree if you are talking about Unit tests. But unit tests won't
guard againsts design flaws: the most expensive kind.
Functional black box tests require a lot of infrastructure to be in
place. Let us suppose we have a custom payrol application and we want
to pay someone. We have an oracle that tells us how much $, sick leave
and vacation he should receive. To pay someone, we must have the a
user interface, employee objects, data base relations, fica, state
withholding, fed withholding, sick leave, vacation and so on... XP is
pretty awsome if I can do all that in one day.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
So what is the cost Pete is talking about? The graphic from Boehm
talks about the cost of fixing defects (or changes - I cannot
remember). But I see you and Pete are talking about the cost of
development because you are talking about testing early to avoid bugs.

I can't speak for Pete, but I can't quite see the difference you are trying to point out between "the cost of development" and "the cost of change". In an iterative cycle, especially one with short iterations, aren't they the same thing?
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
I agree if you are talking about Unit tests. But unit tests won't
guard againsts design flaws: the most expensive kind.

Ah, but that's one of the "tricks" of XP. Unit Tests + Relentless Refactoring + Pair Programming can guard against design flaws. In such a system no design decision is set in stone, but subject to refactoring and improvement as changes are required. By keeping the design always in sync with the requirtements at any point in time, you can effectively remove the necessity for big, expensive, rewrites.
Jeremy Thornton
Ranch Hand

Joined: Feb 21, 2002
Posts: 91
Isn't the entire premise of XP to shorten the time it takes to receive feedback about coding errors ?
By utilising continual integrated unit testing with the build process, errors are found quickly - this has nothing to do with the cost of change during initial development - but it's nice.
With a unit testing framework in place, wholesale changes to code can be made without the all too familiar plague of undiscovered knock on effects. This means that you can be pretty cavalier with your approach to change and just knock through changes and roll back if things start to get very scary. This does have a direct impact on the cost of change.
Don't need to prove the benefits mathematically to be certain that XP (unit testing in particular) helps me.
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
As Kent Beck goes to some pains to remind readers, XP is not just a set of independent techniques, it's also a the sum of using all these practices together. You are unlikely to see the really big "wins" by using just one of the practices; they all reinforce and enhance each other.
I use all except Pair Programming at the moment (because I'm currently out of work, and there's only one of me!), and I'm still amazed at how productive I am, and how clean the code I produce tends to be. I keep feeling, too, that Pair Programming would help me get over the last hurdle - staying focussed on the task at hand.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Siegfried Heintze:
And how is this different from UP where there is a lot of testing too?

It isn't inherently different, because XP *is* an instance of the UP.
But a lot of testing isn't all there is to get feedback - you also need to write and run the right tests of the right granularity at the right time.

> > (Oh -- Pete does mention that the cost of changes will flatten because
> > Boehm in 1981 claims that the smaller the team, the less dramatic the
> > rise. Boehm says the cost of change is 100:1 for a large team but only
> > 4:1 for a small team. This is another week argument on Pete's behalf).
>
> Why is this a weak argument???
4:1 is still extremely high. Is Pete saying 4:1 is acceptable?

No, *Boehm* said that for some projects 4:1 might be acceptable.
Here is what Pete says (p. 120):
"I would content that modern object-oriented development environments are way more powerfull and productive than the prototyping environments that were available back in 1981. Couple this with the Test First Development practices and it would be easy to imagine that a team could do better than a 4:1 cost-to-fix increase."
Where
is the evidence that allows Kent to say the curve becomes
asymptotically horizontal instead of asymptotically vertical like
Boehm says? The shape of the curve is very important.

It's mostly anecdotal evidence from dozens of projects were he and others experienced it.

> I think one of the contributing assumptions of the Boehm curve is that
> late changes in design will affect many parts of the design. As OOP is
> a technique to decouple designs, it might contribute to reduce that
> effect.
Hmmm... that assumes you are not using a relational database
(RDB). These beasts are not OO.

In a good OO design, only a small part of the system needs to know about the database at all. That part is most often called the persistence layer.

Actually, OO could be a good argument! However, it is a poor argument
because I don't believe most programmers understand decoupling as it
relates to OO.

They will have to learn if they want to work test first. Again, test first development efficiently *enforces* strong decoupling (the more coupled a design is, the harder it is to test).
Here is an example:
When you create a modeless dialog box, the parent (perhaps the model
or the view object) must contain a pointer to the dialog (because some
function is going to create the dialog and return without invoking the
destructor). However, the dialog, because it is modeless, must contain
a pointer to the parent which makes it tightly coupled. One easy
resolution, is to use multiple implementation inheritance to add a new
special ancestor to the parent that the modeless dialog can point
to. Java and C# programmers don't have implementation inheritance and
many C++ programmers are to scared to use it.

I think I don't fully understand that example. Can you provide some code, please? Thanks!
If XP programmers are
going to do the simplist thing that could possibly work --- you can
forget decoupling!

I think you misunderstood what XP programmers mean by that phrase. The simplest design XP programmers strive for by relentless refactoring is defined as
1) runs all the tests
3) expresses everything that needs to be expressed
2) contains no duplication
4) has minimal number of classes and methods
(in priority order)
These rules lead to a very well decoupled system in general.

> > It seems there are a lot of tests that cannot be run immediately.
> >
> I don't understand this statement - test-first tests will pass
> in terms of minutes after written, by definition...
I agree if you are talking about Unit tests. But unit tests won't
guard againsts design flaws: the most expensive kind.

They do, as a testable design invariably also is a decoupled design. Additionally - as Frank already pointed out - they also considrably reduce the costs of design flaws by providing a safety net for relentless refactoring.
Functional black box tests require a lot of infrastructure to be in
place. Let us suppose we have a custom payrol application and we want
to pay someone. We have an oracle that tells us how much $, sick leave
and vacation he should receive. To pay someone, we must have the a
user interface, employee objects, data base relations, fica, state
withholding, fed withholding, sick leave, vacation and so on... XP is
pretty awsome if I can do all that in one day.

To pay the first employee, I neither need a user interface, nor a database nor other expensive infrastructure. I also don't need an expensive infastructure to write the first Acceptance Test (is the functional tests defined by the customer are called in XP). All those infrastructure can be evolved with the functionality of the system.
But you are certainly right: XP is pretty awesome...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Cost of Changes Flattens with Time?