Software Reality
Extreme Programming

Site Map

XP Central
Case Against... Songs

Use Case Driven
Use Case Driven Object Modeling with UML: Theory and Practice
Get from use cases to working, maintainable source code. Examples use Spring Framework, JUnit and Enterprise Architect

Agile UML
Agile Development with ICONIX Process
A practical subset of agile development techniques, illustrated by example

Get Controversial!
Extreme Programming Refactored
Extreme Programming with a dose of satire
Available now:

Extreme Programming

Message Forum - Archive, Page 2

Message Index

Keep things in perspective
Jim Villani

re: Out of context

re: Keep things in perspective

Question to Ron
Les anon@nospam.please

re: Out of context
Don Wells

Can XP work as an open-source project?
Andy Dent

Refactor Mercilessly
Jack Humphrey

XM: Extreme Management

XP deserves more credit
Robert Brown

A Nautical Analogy
Glade Diviney

re: A Nautical Analogy

The Messages
Keep things in perspective
I approached XP with a healthy dose of skepticism driven by my 10+ years developing software. What I found, though, was a set of not-new practices that made me a better programmer (previously thought to be inconceivable :-) ).

Youīve got to know when XP (or any of the agile methods) are appropriate. If you are building "flight trajectory calculations for [a] missile targetting system," you shouldnīt even be thinking about XP or agile. For Godīs sake, get those requirements down, in stone, simulated, have the engineers look them over, and so forth. A mathematical simulation of airline industry economics (yawn) being specified by an economist who is still trying to work out the details of the analysis was a good target for XP.

Obviously, you have well-founded reasons for why you (personally) should not use XP. Good for you. I guess I wonder why you care so much about how other people are building software. Iīm sorry, but Mattīs unfounded (as in no-research-to-back-it-up), cynical, and argumentative bad-mouthing of XP contributes nothing to a healthy debate of software practices. Do what works for you.

When XP fervor eventually goes gently into that good night, many of the practices that XP promotes will linger simply as good ways to program.

Jim Villani
Virginia, US

Mon Dec 31 15:49:28 EST 2001
re: Out of context
> Many of the quotes from the XP source materials
> are taken out of context.

Which ones?
That isnīt a "posturing" question, I would seriously be interested to know.

> Consider for instance
> your own article The Case Against XP where you
> state "I have... gone to dig ditches by the side
> of a road somewhere." Did you really mean to say
> that?

Well done, youīve cunningly uncovered the articleīs hidden subtext :o)


Mon Dec 31 16:01:09 EST 2001
re: Keep things in perspective
> I approached XP with a healthy dose of
> skepticism driven by my 10+ years developing
> software. What I found, though, was a set of
> not-new practices that made me a better
> programmer (previously thought to be
> inconceivable :-) ).

I agree, XP does promote some good practices (as I mention in the articles). Iīm glad they improved your programming.

And youīre right about the "missile targetting system" example not being entirely appropriate. Iīll improve that part of the article soon. Thanks for pointing that out.

You wonder why I care so much about how other people are building software? Yes, your World would be a much better place if more people stayed silent about their beliefs.

If you strongly believe a software practice to be flawed, how can you "bad-mouth" it without appearing to be cynical? The articles are based on real experience of what works and what doesnīt in software development, so your assertion that they are "unfounded" is itself unfounded.

Just read the articles for what they are: one programmerīs opinion (as the first article clearly states at the beginning).

London, England

Tue Jan 01 07:07:26 EST 2002
Question to Ron
Ron wrote a while back:

> The article on XPīs values is flat incorrect
> in some of its characterizations, and
> draws conclusions that are not borne
> out in the many projects that are doing XP.

Would you care to mention at least just a few of them, or even one, just to get the ball rolling?

You see, at the moment, your responses to Matt are that he is wrong or misleading, but until you specify where he is wrong or misleading, and why.

By refusing to even start going into detail, you seem to acknowledge that Matt is right, but for some reason dare not admit it.

Les anon@nospam.please
NB, Canada

Fri Jan 04 11:15:34 EST 2002
re: Out of context
You have pointed out a contradiction that is explained clearly at my web
site provided you read the entire page and not just the quotes. The
contradiction is in the idea that XP practices all support each other. They
do. Used together they are much easier and work fairly well. However, you
can use one or two to solve a specific problem that you might be
encountering. But the catch is that it requires extra effort when applied
that way. The good news is that most people are more than willing to put
forth the extra effort to solve the biggest problem they have. But, adding
practices piece meal is an up hill climb and it is easy to slide back down.
I donīt find this to be a contradictory statement.

The jig saw puzzle quote is taken from a page about traditional methods
being largely monolithic while XP is comprised of practices. Doing only one
practice would in most cases make no sense but is not necessarily a crazy
idea. Unit testing on itīs own is not a crazy idea is it? But if that is
all there is to a methodology it would make no sense. It is only when all
the practices are present that a reasonable methodology emerges.

"Together developers and customers move the cards around on a large table to
create a set of stories to be implemented as the first (or next) release. A
useable, testable system that makes good business sense delivered early is
desired." This is not intended to imply the entire system is delivered
early. You are correct, that would be ridiculous. It is in the context of
deciding which user stories to do next. Choosing a set of stories which
will be of value to the customer should only a portion be released seems to
be a good idea to me. Why not let the partially finished system be of use
to someone? I have done this on several projects even pre-XP and believe me
it is appreciated.

From your web site "Your co-worker comes round and tells you your code must
compile perfectly in five minutes, ready for integration." This is
ridiculous of course. You must have misunderstood. Integration is when you
are ready and is never forced, ever. This is fully explained on I will make this
more clear on the integrate often page.

From your site "The example given here is amazing." That example is a toy
example and an attempt to put on paper that which defies being put on paper.
You know this. Letīs keep this above the belt, shall we?

This is not to imply that some of your concerns are not valid. Negotiation
of contracts, especially fixed cost are always problematic. XP does not
change this, but XP does try to alleviate the problem some what by at least
making a best effort to deliver a system that the customer actually wants
and can actually use to solve the problem in question. I have been in the
software industry a bit longer than you and have seen many systems delivered
and never used because they implement the specification but do not solve the

Your criticism of on-site customer is well founded. There is a problem
getting the right customer for the job full time. But shouldnīt we ask some
more fundamental questions? How much is this application really worth? Is
this really a candidate XP project? In many cases the project should not be
attempted with XP because it is not valuable enough to warrant an on-site
customer of appropriate experience level.

It has been my experience that many customers who might seem to not know
what they want actually do. They know exactly what problem must be solved.
What they donīt know is how this god-awful computer technology could
possibly help in any way! These customers are the most difficult, most
common, and hardest to get clear specifications from. But they do know what
they want, you just need to figure out what the correct questions to ask
are. If you can figure that out up front then BRAVO! My experience has
been that the best way to figure out what to ask is to do it in the concrete
context of the system that has been built so far.

There was a section in there about polluting the customer with technical
details and I can not seem to find it just now. That seemed like a
reasonable concern to me. Did you remove it? One does need to be aware of
when a specification is made based on real need or a misconception of what
is really possible. This is true of all projects. The difference here is
that as you grow to know your customer on a face to face basis you can
usually tell when he is just settling because of perceived technological
constraints or is actually telling you the requirements are not that

I like the quote from your site "Only amateurs try to come up with īfancyī
moves" if only Rational would realize how true this is. If you meant to
imply XP is a fancy move you might want to take that off the page. Everyone
who has looked at the web site knows XP is many things, but not fancy.

Don Wells

Don Wells

Sat Jan 05 17:45:16 EST 2002
Can XP work as an open-source project?
I donīt think so.

Iīve been working in an XP-like environment:
- very close cooperation without being in actual pairs,
- high rate of CVS checkin,
- stand-up meetings,
- refactoring as required (fully justified)
- unit testing for core areas but not fully test-first (lotta GUI and the overhead is too much)

most of all itīs a team environment focussed on the team meeting deadlines each week.

I also have my own software company operating in a distributed manner and have been trying to achieve some of the same robust, high-productivity results.

I canīt.

I have come to the conclusion that major OpenSource projects that are seen as highly productive are probably productive in the sense of results but if you evaluated the total cost of person hours would not be optimal or even moderately efficient.

I donīt think XP or other intensely-focussed Agile methods are possible in a distributed manner, unless there are some exotic support tools that "eliminate distance" (Andy chokes slightly on marketing-speak).

Andy Dent
Perth, Western Australia

Mon Jan 28 14:16:04 EST 2002
Refactor Mercilessly

In the Key Rules and Tenets section of your Case Against XP, Iīm not sure you have the right idea about XP and refactoring. Now, I donīt claim to be an XPer, and this may just be an example of a topic on which the XP literature contradicts itself, but I donīt think XP encourages over-optimization of code. In fact, quite the opposite. I remember in the XP Explained book, Beck gives the example of implementing something with a brute force method, then only optimizing it if necessary.

Not that I think that approach is always appropriate, but the general mindset is good. In some cases, a software developer can rely on his experience with the performance of different algorithms to choose the one that is best. No point in choosing the easiest to write algorithm if you and your team-mates are >90% sure it wonīt be good enough.

At any rate, I agree with what you are getting at: "Only optimize where optimization is necessary." Iīm just not sure that viewpoint is in opposition with XP.

Jack Humphrey
Austin, Texas, USA

Mon Feb 18 21:35:34 EST 2002
XM: Extreme Management
I read a Cutter article the other day that said something like the following:

> ... Often, these situations require radical
> approaches. For example, it may be necessary
> to tell the business that IT cannot meet all of
> the commitments it has made, but it wants to
> meet the top three or four. If -- and this can
> be a big "if" -- the business will at least
> identify its top three or four needs, then IT
> must meet its commitments. As the first
> commitments are met, the next most important
> are addressed, and they too must be met. This
> is the only way to build a record of success
> that can anchor a better business-IT
> relationship ...

Interestingly, this is similar to the approach taken by XP in matching requirements to functionality over a fixed release cycle.

This observation has lead me to a new idea that I am tossing around which I am calling "Extreme Management".

XM Key Features:

- "Extreme(ly) Testing": The patience of engineering staff is tested time and time again as clueless techno-philistine managers argue the toss over such business-critical issues as:
- "Is my data interchange format XML?"
- "You should be using Sybase tables as a persistent message store!"
- "Thatīs easy - itīs just a matter of turning on replication."
- "Messaging! Rubbish, whatīs wrong with FTP?"

- "You Arenīt Going to Need It (YAGTNI-tm)":
Strategy? What strategy? We donīt need no stinkinī strategy!"

- "Continuous Reorganisation": Bored? Have a meeting? Better still, reorganise your team, group or even division! Itīs easy if you follow these 4 simple steps:
Step 1: Create new, sexy acronyms for your team, group or division
Step 2: Move people around, preferably between buildings and floors
Step 3: Reduce available employee desk space, particularly for support and infrastructure staff (ie those with the most kit)
Step 4: Watch that bonus figure climb!

So, get an XM programme working in your team today!

NSW, Australia

Thu Feb 21 23:42:00 EST 2002
XP deserves more credit
You say:

"...However, RUP is still light-years ahead of XP in terms of pragmatism and sheer common sense. The main advantage of RUP is that none of it is really new: it is all based on best practices that have been tried and proven in the field, many times over. (This is as opposed to XP which is also nothing new, but is based on unstable practices that used together prevent each other from toppling over)."

So what you´re saying is that RUP represents stable (existing) practices whereas XP represents unstable (existing) practices.

This is perhaps the key point! Is it always possible to use (or misuse) an existing practice? YES.

Do some RUP projects fail? Some will.
Do some RUP projects succeed? Some will.
Do some XP projects fail? Some will.
Do some XP projects succeed? Some will.

I think that the entire point of using XP is to prove that these practices can be stable if done correctly. We must remember that any method or methodology can be done to any level, good bad or ugly.

I firmly believe that XP (or RUP for that matter) can work if you:
A) Give it a chance
B) Really sincerely follow the intent of the method
C) Understand the limitations of that method!!! (Maybe the most important.)

The thing that impressed me so much about XP was the fact that the authors (like Kent Beck) not only talk about how the practices can work, but how they can fail as well. I think this is what is the real difference between RUP and XP. I read several of the RUP books and, if I remember correctly, there was nowehere near the emphasis placed on failure modes. Nowhere was there a warning like this: "Be careful how much documentation you produce because you can run the project out of time/money by doing it."

In summary, I think XP deserves more credit than you gave it because I believe it can work. Think about doing the opposite of all the XP practices; would that have a chance in hell or working?

* No planning
* Big infrequent releases
* No metaphor
* Complex Design
* No testing
* No refactoring
* Nobody helps anybody (no pair programming)
* No collective ownership
* Big infrequent intergration
* Constant Overtime
* Customer not available or unresponsive
* No coding standards

How many of us out there have been on projects like this? ;)

Robert Brown
Jax, FL, USA

Thu Mar 07 13:02:02 EST 2002
A Nautical Analogy
Matt Stephensī XP article sounds like a guy on the bridge of an aircraft carrier who sees a sailboat whip past. He chortles to himself, "What an immature vessel. If one of its subsystems failed (hull, mainmast, sail, etc.) it would be utterly incapacitated. And I bet its captain isnīt even sure of where heīs going! OUR course is plotted to the nearest centimeter. He doesnīt even belong in the water."

Perhaps what the author fails to realize is that a majority of developers have no clear process AT ALL, that is, theyīre trying to cross the bay without even a boat to carry them. I suppose Matt would suggest they paddle back to shore and wrap themselves in several thousand tons of steel before they try again.

Glade Diviney
Oregon, USA

Fri Mar 08 12:15:18 EST 2002
re: A Nautical Analogy
Glade - the trouble with analogies is that they mean everything and nothing.

For example, you remind me of a frog on a rollerskate - but Iīm not going to say why.

Iīm not a big fan of "heavyweight", high-ceremony methodologies. However, itīs a mistake to think that RUP is necessarily heavyweight. In any project you just use the parts of RUP that you feel you need, i.e. it can be very lightweight. Itīs up to you.

Iīm all in favour of the GOALS of agile methods - just not XPīs way of achieving them (why? - read the article).

Too much process can get in the way, and you risk losing sight of your original goal.

London, England

Sun Mar 10 15:06:01 EST 2002


Page 1 (earliest)

Page 2

Page 3

Page 4

<< Back to XP Central

<< Back to Software Reality

All trademarks and copyrights on this page are owned by their respective owners.
Stories and articles are owned by the original author.
All the rest Copyright Đ 1998 onwards Matt Stephens. ALL RIGHTS RESERVED.