Re: XP Question about Metaphor

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 11/19/03 

Date: Wed, 19 Nov 2003 18:12:02 GMT

Responding to Jeffries...

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

This has just defined a finer granularity to the waterfall. You have
simply subdivided a monolithic waterfall into mini-waterfalls.

To me there are two issues in the BDUF discussion:

(1) is there design up front within the project or the increment
waterfall in XP?

I assert that there is because of AS and SM at the project level and
CRCs and refactoring at the increment level (however small that
increment is scaled). The only disagreement I have heard here is about
whether refactoring is up front and scales finer than story (more on
both below).

(2) is the design for XP really is smaller than in BDUF?

You stated in the last message and later in this one that you felt XP
did /more/ design than other processes. The disagreement here seems to
lie in whether the B in BDUF means actual size (proportional effort
within the waterfall) or scale (size of the increment). I think any
interpretation other than actual size is a stretch. [More in discussing
DDDDCCCC vs. DCDCDCDC below.]

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

I think it is point of difference. I assert that the /benefit/ of
refactoring, such as removing code duplication, is only gained in
subsequent increments. Therefore, though it is methodologically
convenient to execute it at the end of the current increment, it is
really an up front OOA/D activity for the subsequent increments.

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

As I understand my XP readings, one always provides preliminary CRCs
whenever a story suggests that new entities may be required. No matter
how finely one defines stories, features, chunks, or whatever one wants
to call them, the CRC (if necessary) is still done prior to the coding
for that waterfall unit.

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

I agree; it is irrelevant to the BDUF issue.

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

That's correct. Refactoring is driven by developer concerns for
maintainability, not customer concerns for correctness. Nonetheless, it
is an OOA/D activity and all of the principles, rules, policies,
guidelines, and practices reflect a rote distillation of OOA/D that is
an alternative to modeling techniques.

The fact that one operates on existing, working code simply reflects
that one is applying OO principles to the code to ensure its
maintainability. Those OO principles are still A&D elements. IOW, the
code prior to refactoring represents the solution to the customer's
problem while the code after refactoring represents a solution to the
developer's problem through the application of OOA/D to developer
requirements.

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

That is, in part, because the distillation of OOA/D represented by
refactoring results in a relatively mechanical exercise. In addition,
code duplication is only a small part of refactoring. The real value
lies in dependency management that produces a DAG, which requires a more
sophisticated application of refactoring.

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

Your first sentence essentially accepts my point (1) above. XP does do
OOA/D and it is up front because even in your AAAADDDDCCCC =>
ADCADCADCAC example above, the OOA/D is always done before the C in the
current increment, story, chunk, whatever, regardless of the waterfall
size. So that just leaves what B means...

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

Being 'closer in time' is just another way of saying one uses smaller
waterfalls.

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

Actually, I think I have mentioned it in almost every one of my messages
since this thread got onto BDUF.

My overall position in this subthread has been that BDUF is misleading
when used to distinguish DDDDCCCC from DCDCDCDC. That's because there
is really no difference in the individual Ds and Cs, other than the
mechanics of models vs. CRC/AS/SM/test writing/refactoring. So the
design isn't any smaller in XP and it is still done up front of the
coding where it provides benefit.

The only real difference lies in the scale of the waterfall. So it
would be much more descriptive to characterize the difference as BW vs.
SW rather than BDUF vs. not BDUF.

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

PSP is completely independent of the tools used to develop the software
or manage the project. [The tools one builds in the class exercises are
just that, exercises. Everyone I know doing PSP uses the OTS commercial
tools of their choice.] All it defines are the sorts of activities that
need to be done; its just CMM for individuals. But let's not go there.

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

I find this really curious. You feel PSP is retentive compared to XP?!?
  XP is the most formally defined and mechanical software development
process I have ever seen! If it were defined with any greater detail
all one would need to develop software would be some reasonably bright
orangutans and a large bag of bananas.

[Don't take it personally; I couldn't resist because it was such a soft
target. I am being facetious just to make the point that it is the most
distilled, detailed, mechanical software development process that I know
of.]

If you recall our previous debates, I always regarded XP as a
heavyweight process because of the very fine level of detail to which
developer activities are defined -- much like the shelf-full of
standards manuals that determine what a telephone repairman does.
Processes that are defined in great detail are heavyweight while
processes that are defined more generically are lightweight. Thus
Design/Code/Test is a lightweight process because is says very little
about how one does things. So I have always found XP's claim to be
lightweight to be ironic.

In contrast, in PSP there is no specification about how one develops the
software. There are no dictums about how to design it, implement it, or
test it (e.g., AS, SM, CRC, test-first and TDD, pair programming, and
the entire body of refactoring).

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

Yes.

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

True, but I don't think the issue is modularity per se. That's true
because the previous increments were Good Citizens and did their
refactoring right, which may or may not have improved modularity. Which
just gets back to the point that posterity gets the benefits of refactoring.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

Relevant Pages

  • Re: XP Question about Metaphor
    ... >>They are in proportion to the size of an increment's waterfall. ... >>time devoted to CRCs, writing tests, and refactoring within an increment ... done prior to writing and testing code. ...
    (comp.object)
  • Re: XP Question about Metaphor
    ... By your definition of waterfall model, ... The first two are done prior to any increment. ... Refactoring for local things like eliminating ... The agile methods I'm familiar with do not advocate design only at the begin ...
    (comp.object)
  • Re: XP Question about Metaphor
    ... >>software development involves a waterfall model at some scale. ... The first two are done prior to any increment. ... There is nothing to prevent one from, say, coding first, refactoring, ...
    (comp.object)
  • Re: XP Question about Metaphor
    ... >They are in proportion to the size of an increment's waterfall. ... >time devoted to CRCs, writing tests, and refactoring within an increment ... not an intrinsic proportion of OOA/D within the waterfall. ... On the one hand, I think that XP has /more/ design in it, not less. ...
    (comp.object)
  • Re: SproutMethod.pdf
    ... Design Paterns book) (i.e. through Factories, ... Refactoring and the other techniques that I write about are in fact ... security and other essential features were lost on the ... > I know how to write good programs sometimes, using mathematics, but as you point ...
    (comp.object)