Re: XP, a Criticism

• Previous message: Harry Erwin: "Re: XP, a Criticism"
• In reply to: H. S. Lahman: "Re: XP, a Criticism"
• Next in thread: Uncle Bob (Robert C. Martin): "Re: XP, a Criticism"
• Reply: Uncle Bob (Robert C. Martin): "Re: XP, a Criticism"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 7 Nov 2003 08:30:12 +0000

H. S. Lahman <h.lahman@verizon.net> wrote:

> Responding to Erwin...
>
> > Extreme Programming has become of interest in the School of Computing
> > and Technology where I teach, so I've been investigating it before
> > covering it in some of my lectures. My background is the software
> > architecture of life-critical systems, real-time systems, and security
> > systems, so I am a bit cynical about an approach that basically puts me
> > out of a job, but I also have a background in evolutionary systems, and
> > that provides a perspective on emergence and evolutionary design (aka
> > refactoring).
>
> Actually, I think Beck is pretty clear that XP is probably not a good
> choice for life-critical systems. He's kind of vague about why in his
> book, but I believe it is rooted in the notion that quality is
> determined through testing.
>
> By advocating test-first and essentially institutionalizing testing in
> the process, XP addresses some potentially nasty problems for
> traditional testing (e.g., having developers write tests after the
> product is developed is psychologically the worst possible time to do
> it). However, it doesn't get around the basic problem that delivering
> reliability beyond 5-Sigma is simply not feasible through testing for
> applications of even modest complexity. To get to 6-Sigma and beyond
> one needs militant process improvement and defect prevention, which XP
> does not address out of the box.
>
> >
> > XP seems to propose a development process that begins with a poor
> > solution to a set of user needs {Ui} and refactors it incrementally to
> > an good solution. It also seems to suggest that you can add user needs
> > incrementally and use refactoring to expand the necessary functionality,
> > with a good solution 'emerging' from the process. There are four
> > criticisms of this approach that come to mind.
> >
> > 1. Unless refactoring is reduced in scope over time, the process will
> > converge to a limit cycle, not a fixed point.
> > 2. The fixed point the process converges to is a local, not global
> > optimum.
>
> XP has other mechanisms to address this sort of thing like the
> architectural spike and system metaphor. So long as the refactoring is
> done within those guidelines, architectural drift and converging to a
> local optimum are minimized.
>
> However, that places a significant limit on application size. IOW, the
> overall project scope needs to be something that can be completed by a
> single team of 5-10 in a year or so. Otherwise informal mechanisms like
> a system metaphor probably won't cut it. One can still deal with larger
> applications (e.g., by partitioning it into subsystems of team scale
> that can be developed concurrently) but it requires the infusion of
> systems engineering functions that do not come with XP out of the box.
>
> > 3. To add user needs to those already handled by the system, the scope
> > of refactoring must be expanded as otherwise the process of convergence
> > will take an extremely long time.
> > 4. Some user needs have to be added as a package, not individually. The
> > approach in XP seems to rely on introducing one at a time into the
> > system.
>
> XP relies very heavily on customer participation and unless a customer
> is readily available for informal specification XP cannot succeed.
> While XP is flexible about who a 'customer' is (e.g., Marketing can
> define requirements rather than an end user), the process still depends
> upon a very substantial commitment of hands-on participation by
> non-software people.
>
> For example, Ron Jeffries once estimated that to keep up with a
> 10-person XP team it would require two full-time customers for just
> writing acceptance tests. While that customer function can be assigned
> to an in-house QA group, somebody still has to provide the story
> requirements to both the developers and the QA people. Because XP
> requirements are provided informally on a largely face-to-face basis,
> that also means that whoever is providing the requirements must make
> sure QA and the developers get the same message in all situations.
>
> Note that each XP increment is a very rigidly defined waterfall model.
> XP depends on the very fine granularity (stories implementable in 2-3
> weeks with features at the ~100 LOC level) of deliverable product. At
> that level the in situ customer participation works well to maintain
> focus because the number or requirements is necessarily quite limited.
> And since the overall project scale is also quite limited, there really
> isn't a lot of room for drift.
>
> In addition, note that XP is an OO process. It depends upon the
> inherent robustness of the OO paradigm to ensure maintainability for
> future increments. The refactoring simply reflects application of basic
> OO principles to ensure maintainability from one increment to the next.
> XP would fail in a procedural environment precisely because
> refactoring is neither well defined nor well supported in such environments.
>
> Bottom line: while I think XP has a number of problems (some in addition
> to those above) that limit it to a much narrower niche than most of its
> advocates would like to admit, I don't see your concerns as a
> significant problem within that niche. IOW, any OO development should
> end up being maintainable if the OO paradigm is properly practiced;
> that's why we do OO rather than functional programming or some other
> approach. I think XP is just ensuring that the OO paradigms are
> practiced by institutionalizing disciplined 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

Thanks greatly. That helps clarify the issues. For a team of 5-10
superprogrammers, I suspect almost any methodology will be successful as
long as it doesn't get in the way of real work. (My specialty back in
the days when I was in industry was coming up with buildable
architectures for systems too big to be built by one of those small
teams.)

-- 
Harry Erwin <http://www.theworld.com/~herwin/>

• Previous message: Harry Erwin: "Re: XP, a Criticism"
• In reply to: H. S. Lahman: "Re: XP, a Criticism"
• Next in thread: Uncle Bob (Robert C. Martin): "Re: XP, a Criticism"
• Reply: Uncle Bob (Robert C. Martin): "Re: XP, a Criticism"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]