There are two subprocesses of XP. They cannot be called phases because they
happen concurrently. These subprocesses are the system design subprocess and the
system development subprocess. The disadvantages are addresses separately. Ideas
come from the
Beck-Cooper interview interview as well as our own thoughts, based on http://www.extremeprogramming.org/.
XP System Design
The system design subprocess of XP is the parts of XP
that occur between people. This subprocess is the more problematic.
XP Assumes Broken Organization
One of the assumptions made by XP is that
the organization is broken. XP assumes that the programmer will be jerked around
by the management or by the customer. XP assumes the programmer will be held
responsible for any failure to meet the deadline or for any complaints. Finally,
XP assumes that a program's requirements will change.
One of the root causes of this problem is that managers and customers don't
really understand software.
Developer and Customer "Speak Different Languages"
XP requires that the
customer always be available to the developer. We will leave aside the issue of
whether this is even feasible. Developers are trained to interact with
computers. Computers are (for the most part) deterministic, and will do exactly
what they are told to do. People, on the other hand, are not so predictable.
Developers are not trained to deal with the customer, and should not be expected
to.
XP intends to be a means to break this language barrier. Snapshot releases
are made every week or two, so the customer can see the progress being made and
general direction being taken by the project. This helps insulate the programmer
from the instability around her.
A better solution, proposed by Cooper in the
Beck-Cooper interview, would perhaps be to introduce a middleman who speaks
both the language of the customer and the language of the developers. He would
act as a translator, so that instead of needing the iterative process of
releases to achieve a design the customer can be happy with, the customer and
designer would agree on a design expressed in the customer's language, and that
design would then be presented to the developers for implementation.
This would result in a better expression of the customer's ideas. The result
is that the requirements don't change in mid-stream. In addition, since the
infrastructure has been designed already, it is no longer necessary to
repeatedly recode a particular functionality, which is unfair to the developers
who coded it the first time and unfair to the developers who recode it.
XP As Blame Transfer
It seems that one of the justifications of XP is to
insulate developers from blame. It does this by giving the developers a means to
work around anything they may get blamed for. The reasoning is that, since the
customer saw what was being developed in snapshots over short intervals, they
cannot blame the developer if they don't like the finished product.
However, the point of a software engineering methodology should not be
blame-transfer. An ideal software engineering methodology should be the one
resulting in the most functional, least-buggy, most efficient code, not the one
which results in least inconvenience or hassle for the developers. While there
may be overlap, there will always be a trade-off.
XP System Development
The system development subprocess of XP refers
processes which occur on computer. These include coding, testing, and
integrating. For the most part, XP coding and testing ideas are sound. They can
result in better and more efficiently written code. There are assumptions here
as well, and not meeting them can cause the benefits of these ideas to be lost.
Pair
programming assumes that both developers are on the same page. If this is
not the case, then the benefits are for the most part lost. In the one case, the
programmer not typing is on the ball, that programmer will find herself
dictating to the programmer at the keyboard. In the other case, the programmer
typing is the one on the ball; either she is typing without explanation, in
which case the other programmer is getting progressively more lost, or she is
explaining as she is typing, in which case she is losing ground.
One of the requirements of continuous
integration is that the integrated code always runs. This process assumes
that once a core component is integrated, it won't change significantly. This
resists changing any such component, even if the redesign is essential. The
interaction between continuous integration and refactoring, which is supposed to
alleviate this problem, is presumably left as an exercise to the coder. It seems
like the result would be a game of catch-up.
arudys@rice.edu
juliew@rice.eduLast
modified: Mon Jan 28 13:15:14 CST 2002