Xp Critique

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

• CRC cards fail when you try to design large systems: The mechanism begins to break down after about 30-40 classes. And CRC cards do not capture the scenarios/interactions between objects.

• Refactoring interfaces is always difficult. When there exist interface dependencies between teams (rather than between objects) you have to strike a balance when it comes to refactoring. You can't be extreme.

• Large scale development usually requires a wide range of competencies and, therefore, multiple teams. Collective ownership of code might be the ideal, but there is no guarantee that one team will share the same tools, development environment, network or geographical location as another.

• XP values courage. Among other things, it is the active involvement of the individual programmer in the PlanningGame which provides that courage. For a large project, this level of collaboration would produce too much overhead. But a team leader who wants the support and courage of his team must involve them somehow. This involvement can be called design. Just as XP does up-front planning, already knowing that the plan is wrong, so must a large project do up-front design, again fully aware that it will have to change. (See BigDesignUpFront)

• ExtremeProgramming would only work on a small project with all the people in the same room. Larger projects would require teams and subsystem breakdown requiring a design notation and design documentation to communicate between the teams.

• It is not unusual for a large organization to take a long time to deploy an application. Delivering in short increments then becomes problematic (see ExtremeDeployment).

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.

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

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

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006