Xp Critique

Critique of large scale XP

Extreme programming can't possibly work with large systems (100,000 lines and up) because...

For a different position on these arguments, see MultiTeamExtremeProgramming.

Critique of XP from a systems perspective

[The following copied from http://www.cwi.nl/~arie/wci2001/ahthing.html]

One of the central features of XP is the clear specification of the interface between developers and clients with the developer on the technological side and the client on the business side. This puts a big burden on the customer role in the XP team.

Most clients have a business problem to be solved. They are looking for a solution which satisfies some stated business goal. They will be looking for a software developing contractor when they think that at least part of the solution can be supplied by an software system.

Thus in reaching their business goal clients have two problems:

  1. Building the right system (including organizational changes).
  2. Building the system right.

XP is an excellent concept for optimizing the economical solution of the second problem, not least by explicitly separating the responsibility for the solution of both problems between the developers and the customer. Consequently the XP approach, by favoring bottom- up design (user- stories) and local optimization (refactoring), does not much support the customer in making sure that the user stories implemented will finally add up to the solution of the business goal.

The main support the XP practices give the customer for reaching his business goal is by reducing the cost of his learning, i.e. changing his mind and thus changing some already existing parts of the system.

Unfortunately the biggest fear of several of my clients was:

"Our software contractor will deliver a software as we want it, not as we need it !"
--JurgenAhting?

Understandable fear. When you're afraid that what you want isn't what you need, no amount of software is going to solve your problem, though. You (the customer, or the customer's organization) must first clarify your goals.

I expect a client will be quite clear on his goals. There will be some understanding that he can revolutionize (or at least improve) some business function and that technology will enable this. He may, however, not know how to get there, and to what extent technology plays a part in the solution. This is where he needs help.

I think the question is this: will 'local optimization' imply or produce the organizational, cultural and (non-software related) procedural changes necessary? If the answer is yes, then I think perhaps XP can revolutionize a business. Otherwise I suspect it will only automate certain tasks. --ChrisSteinbach


See XpCritiqueDiscussion, CritiqueOfXp
CategoryXpCritique
EditText of this page (last edited February 4, 2003)
FindPage by browsing or searching

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006