Re: Agile developement ... more than just extreme programming ???

From: Ron Jeffries (ronjeffries_at_REMOVEacm.org)
Date: 11/18/03 

Date: Tue, 18 Nov 2003 07:56:01 -0500

On Tue, 18 Nov 2003 20:53:54 +1100, Sean Case <gsc@zip.com.au> wrote:

>>>> The reason, I think, is pretty clear -- it takes the same amount of code to
>>>> implement B then A as A then B. Assuming that our rate of producing code is
>>>> reasonably constant, the work is the same across either path.
>
>>> How does the rate of deleting code relate to the rate of producing it?
>
>> Surely deletion is pretty fast. Producing duplicate code is also very fast.
>
>OK, then we can more or less ignore the cost of deleting code. But we can't
>ignore the cost of writing the code that is deleted, unless we constantly
>duplicate code and then delete it. And we will delete some code.

Thanks for a well-reasoned and professional posting.

Yes, surely we will delete some code, and there is a cost to writing it.

I'm going to digress here for a moment, to describe how I'm trying to address
this general topic, and then I'll return to your remarks, I promise.

I think we're mixingat least two ingredients here, and I've been trying to
separate them. The ingredients I see are

  (1) is it, or is it not mathematically inevitable that changing the order of
development must change the cost?

  (2) how does the answer to (1) play into incremental development?

I believe that it is clearly NOT mathematically inevitable. If, for example, we
know the design perfectly, we can clearly deliver features in any order by just
writing the necessary code. No matter what order we chose, the time to the
/last/ feature would be the same. (Of course, the time to the /first/ feature
might be quite different.)

I'd like to get this item (1) agreed to, or understand why we can't agree,
because I believe it's contaminating the discussion: arguments are mixing up
"refactoring" with "order of implementation".

If we could decide that /in theory/ we can be order independent if we know the
design, then we could begin to work on (2), doing things incrementally.

The dimensions I would like to explore in (2) include these:

  - How much "extra" work occurs via refactoring when we do incremental
development? I believe it's small, and to the extent that it is, matters to be
listed below might make us willing to be more order-independent.

  - How much "extra" work occurs from overdesign, creating a more robust
framework than we /ever/ need on the project? It might not take much overdesign
to balance a little refactoring.

  - How much of the full design can just be left out until later in the project?
Often there are "framework" capabilities that can be deferred. Perhaps some
features might be delivered before full robustness is put in.

  - How much learning about the application comes from early release of some
features? We would all wish that customers knew just what they wanted, but they
do not. Most of us do not even know exactly what /we/ want. Realistically, we
can get a better product if we can show the customer what he's going to get. One
way to do that is to spend money on prototypes. Another way might be to use that
money to develop the real product in a different order.

  - How much value is there to shipping part of the product? Perhaps there are
key capabilities that people would pay to have. We might bring revenue in
earlier, and have a better net value growth by doing things in a different
order, even it if was sub-optimal from some internal viewpoint.

So anyway, I'm trying to dissect out these topics for rational discussion, to
move beyond the low-level badinage, on to an exploration of when and how to
deliver better software sooner.

OK, enough groundwork ... now back to your points.
>
>That's the way things work. You write some code, you rewrite it, you have
>an attack of refactoring, you take some code out. Now, XP holds that we
>shouldn't be afraid of writing code that will be thrown away later; that the
>benefits of having some code in place ASAP outweigh the costs of churn. But
>this is beside the point.

Well, I would say that it is an important point, one that some folks (not you
and me) are missing: how much waste is there, if any, and how much waste will we
accept in return for learning or revenue?

>The claim was that the time taken to produce a
>program was insensitive to the order in which features were implemented, and
>the justification given was that the program ends up the same size in either
>case. Once you realise that the same program may be reached by different
>routes, it seems obvious that one path might be harder than another.

Yes, I agree. But my point is not and was not that time /is/ insensitive to
order, but that it /can be/, that it /might be/. My intention is and was to get
us looking at the dimensions listed above, so that we can figure out where the
tradeoffs are, and make good decisions about what to do first.

  I find that XP teams quickly become quite good at building infrastructure
incrementally, and delivering things in an order that pleases their customer,
while keeping the code clean enough for the long term. I'd like to understand
better how that works, and I'd like more people to see that it's possible, so
that they might benefit.
>
>Let's take an example: suppose we have requirements A and B, and decide to
>do A first. And suppose that we discover that A needs some infrastructure,
>either a nice simple I1, or the more complex I2. B, on the other hand,
>won't work with I1. It really needs I2 to be in place.
>
>Now, if we implement B first, then by the time we come to A we've already
>built an I2; it's arguably overkill for A, but B needed it, and we might as
>well re-use it. So we've built B + I2 + A.
>
>What if we build A first? If we didn't know about B, we would presumably
>prefer to use an I1. But if B turns up later, we'll have to build I2 anyway
>and I1 will be refactored away. So we'll have built A + I1 + B + I2, since
>we don't get the time back when we delete I1.
>
>If we already know about B at the beginning, then maybe we'll build I2 even
>though it's not strictly necessary just yet. But the more fervent XP
>supporters will call it goldplating...

Yes, but no. My point (1) is that we can, if we choose, build I2, B, A, or I2,
A, B, in the same time. It may well be true that going through I1 is slower, but
the first point to get clear is whether (or not) we can build A, B, or B, A, at
the same cost.

Those who favor full design ought, I'd have thought, to agree that they can
deliver features in any order. Yet they keep saying, no, there is some optimal
order. I don't understand that, and I'm trying to figure out why they think it,
net of Pigs in Space.
>
>Now this is why the "order does matter" people have been saying that you
>look at technical risks, you start with a sample of requirements from
>different areas, and so on. I don't think XP explicitly excludes this sort
>of thing, but certain XP supporters exaggerate the extent to which they can
>"prove" things about their development processes.

I wouldn't know. I'm trying to dig into some numbers to see if we can tease out
things we already agree about, things we can model to learn about, things that
need experimentation or further analysis, and so on.

It seems to me that when people disagree, there is learning to be had. I'm
trying to ignore the name-calling and get down to the learning. Perhaps you'd
like to join in that endeavor?

Regards, 

-- 
Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

Relevant Pages

  • Re: Could Falcon 9 compete with the Stick?
    ... >> Ed Kyle wrote: ... >> built to government specs, ... include this option, instead reducing the cost. ... features drive the first 90% of the cost, and the last 10% of features ...
    (sci.space.policy)
  • Re: Windows forms application without Managed Code?
    ... and want to do a major rewrite for other reasons as well. ... that a complete rewrite is going to cost $50,000. ... gamut of features from a possibly more productive development environment, ... user interface, but, utlimately, it does exactly what it is already doing. ...
    (microsoft.public.vc.mfc)
  • Re: Separate the front-end from the back-end for simple applications
    ... >know will eventually be used in a multi-user environment, you should design ... >might not make the best decisions and will probably cost you more time to ... But for learning, I'm trying to eliminate as many ... >> Running MS Office 2K Pro ...
    (microsoft.public.access.gettingstarted)
  • Re: What next for Sun Fortran?
    ... Knowing which of the new features users want most would ... derived-type I/O pretty much requires rewriting the ... UDDTIO is my personal candidate for the worst cost/benefit ratio of all ... The cost is large. ...
    (comp.lang.fortran)
  • Re: Agile developement ... more than just extreme programming ???
    ... then we can more or less ignore the cost of deleting code. ... > Yes, surely we will delete some code, and there is a cost to writing it. ... The excessive testing effort implies the time to ... > deliver features in any order. ...
    (comp.object)