Re: XP Question about Metaphor

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

Date: Tue, 18 Nov 2003 18:08:52 -0500

I confess that I'm not sure what is happening here, i.e. whether either of us is
espousing a position, and whether the other agrees or disagrees. I feel that
we're just kind of narrowing in on terms or something. Anyway ...

On Tue, 18 Nov 2003 20:49:56 GMT, "H. S. Lahman" <h.lahman@verizon.net> wrote:

>> So in XP, I think there is lots of design -- it goes on all the time.
>
>That's true of any development if one defines 'design' fine enough.
>When doing OOP one is necessarily doing tactical design as the code is
>being written.

Yes. However, I have seen many projects where it seemed that design had stopped
and instead code was just layered on like more paint over old paint.

In reaction to that, it seems, some people recommend doing more design before
"jumping into coding". (They seem often to use that phrase for some reason.)

I would almost certainly recommend doing more design /during/ coding, and
depending on how much design /before/ coding was being considered, might or
might not feel it was desirable.
>
>But the issue here is design in the sense of OOA/D. Not matter what OO
>process one is using, one needs to do OOA and OOD prior to OOP. I argue
>that AS, SM, CRCs, and refactoring are all OOA/D activities and they are
>done prior to writing and testing code. Hence the assertion that DUF
>exists in XP.

Well, yes and no. I believe that when many people say analysis before design and
design before coding, they are thinking like this:

AAAADDDDCCCC.

I think we are mostly agreeing here that an incremental process like XP is more
like

ADCADCADCADC

where the A and D for any given thing typically precede the C.

However, I also believe that refactoring by such means as observing duplication
and removing it amounts to designing /after/ coding. That may or may not be a
point of difference between us, though it seems clear to me that that's what it
is. And if we do differ, I'm not sure what different conclusions we might draw
based on those different starting positions.
>
>[AS and SM are done prior to /any/ code writing in XP. CRCs are done
>prior to any code writing within a given increment.

Well, they /might/ be done prior to coding that thing. They are not necessarily
done prior to coding some other thing in that iteration.

Further, CRC, for example, might well be used to describe a design thta exists,
not to plan one. That, again, is "after coding". But I'm not sure what
difference it make to anyone's point.

>The thing that is
>unique to XP is the notion of doing refactoring at the end of an
>increment. However, I assert that such refactoring is done as part of
>OOA/D for the benefit of subsequent increments; it just happens to be
>convenient to execute it in the current increment.

This is an interesting model, and certainly that design improvement is being
done with some kind of eye to the future. However, unlike the two of us sitting
down and designing X, refactoring is often done just to make the world a better
place, with no particular X in mind. To that extent, it may be a different kind
of thing -- and again I'm not sure what difference it makes to any points we
might like to make. If it did, it would be more interesting than as just a
technicality of language.
>
>As you pointed out in another message, some refactoring in XP is done
>prior to coding. However, in that case it is clearly OOA/D prior to
>coding. In either case refactoring is an OOA/D activity that is done
>prior to the coding that it benefits.]

Well, sometimes. But duplication removal, for example, while it does improve the
design, doesn't feel to me that it is exercising the same brain cells as "real"
design does. That could be a personal problem, of course.

And again ... one usually thinks of design as directed to some kind of thing one
is trying to build, like preparing the menu for tomorrow's dinner. Refactoring
is often more like cleaning up the kitchen.
>
>So...
>
>>
>> However, it is not "Big", in the sense that it is done in little tiny bites, not
>> big phased kind of bites as classic Waterfall seems to contemplate.
>
>This seems to be arguing that the effort isn't Big so long as it is done
>incrementally with fine granularity. I am thinking in terms of total
>effort devoted to OOA/D in any given waterfall execution. In those
>terms I don't see any difference between XP and other approaches, other
>than the size of the waterfall. That is, what counts is the proportion
>of effort devoted to OOA/D /within/ the waterfall and you seem to agree
>(in your second paragraph above) that XP's proportion is at least as
>large as for the modeling alternative.

Yes, I would generally argue that XP, done properly, does more "design work",
however we might define that, than many approaches, particularly ad-hoc
approaches, which of course we all abhor. I would also argue that many
recommended practices are more like basic waterfall than XP is, in that they
recommend a larger batch of design before beginning any coding.

So I think there is a real difference in what agile methods are saying about the
best time to do design, i.e. closer in time to the building of the thing. I
would agree with what I understand you to be saying, namely "Yes, but it is
still [usually] /before/.

(It would be tragic, although historic, were we actually to agree on something,
wouldn't it? ;-> )
>
>>
>> And it is not "Up Front" in two senses: first, as mentioned above, it goes on in
>> each iteration, not loaded toward the beginning of the project. Second, even
>> during an iteration, there is as much or more consideration given to the design
>> of a chunk after that chunk has begun to be programmed, which seems to me not to
>> be up front in any sense.
>>
>
>Each iteration is a waterfall. XP is just making the waterfalls much
>smaller than typical modeling projects, which is why I keep saying that
>XP should be railing against BW rather than BDUF.

Yes, though I hadn't noticed you repeating it all that often. We do use the
phrase BDUF to mean the DDDDCCCC sort of thing as opposed to DCDCDCDC, and
arguably we should refer to waterfall when we want to talk about that.

>However, there is
>nothing to prevent modeling approaches from adopting such fine
>increments except the constraints of the external environment. In our
>shop we routinely did feature-based increments and not uncommonly
>features happened to be on the scale of stories (though most weren't).
>In fact, any bug fix that involves a minor change is exactly that sort
>of fine-grained increment and that sort of thing is done routinely in
>modeling environments.

Indeed.
>
>As far as the chunks are concerned, check out Humphrey's Personal
>Software Process. That is classic CMM BDUF applied to code fragments (<
>200 LOC). Each "chunk" is still done as a waterfall and for that chunk
>one analyzes and designs prior to writing code.

Yes, and does a number of things with which I fairly emphatically do not agree.
I believe that PSP does not take ideal advantage of today's tools, which I
believe shifts the balance between what the human should keep track of and what
the computer should keep track of.

I could be even more wrong than usual about that, and freely admit that I have a
personal inability to behave anywhere near as retentively as PSP would demand,
so it might just be that inability speaking. But I don't think so.
>
>In addition, the context of XP refactoring is broader than a chunk; it
>is essentially the entire software product to date. IOW, any object is
>fair game for touching in ensuring a DAG.

DAG? Directed Acyclic Graph? Well, no matter.

It is true that any object is fair game in principle. In practice, in fairly
well-designed code, most refactorings only address a very few objects. That's
because modularity generally works, in my opinion.

So where are we? Are we agreeing on some stuff? Should we hammer down a few
drinks and try again? ;-> 

-- 
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: Is top-down design feasible for a coffee-break roguelike?
    ... fundamental design decisions should be settled before doing coding.. ... is strongly linked to the game mechanics itself. ... but simply because it assumes diagonal movement is disallowed. ...
    (rec.games.roguelike.development)
  • Re: truly-optimized coding styles & design patterns in C#?
    ... grokking design patterns but try to find practical examples of each pattern ... apps you've written and seek out the simplest and most elegant ways to ... creating a small utility app vs coding something that has to fit into ... > exceptions classes, none of that. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Commenting the source code.
    ... > Do you comment your source code while coding or after coding. ... break down the design to be more specific ... write, document, compile and debug debug fuctions. ... Whereas successfull means dedect bugs, ...
    (comp.lang.c)
  • Re: DAB+ to use UEP - Homer Croiset exclusive
    ... the spec to be released to find out what the new error correction ... correction coding. ... called me an idiot for being stupid and not understanding economics. ... You don't design a ...
    (alt.radio.digital)
  • Re: XP Question about Metaphor
    ... > design before coding, ... This has just defined a finer granularity to the waterfall. ... is there design up front within the project or the increment ... whether refactoring is up front and scales finer than story (more on ...
    (comp.object)