The #1 Serious Flaw in Extreme Programming (XP)

by Conrad Weisert
© 2002 Information Disciplines, Inc., Chicago

NOTE: This article may be circulated freely as long as the copyright notice is included.

Related articles on this and other web sites
as of October, 2003
Agile Methods and Torpid Programmers
The #2 Serious Flaw in Extreme Programming
Software Reality web site -- articles, book reviews, and experience reports
Book review: An Extreme Programming Book for Non-Extremists

Background

Growing popularity

Kent Beck1 and his colleagues and disciples have been putting forth a vigorous case in favor of a "new" software development methodology, based partly on common practices from the 1960s. Extreme programming (XP) has been attracting attention and gaining adherents, appealing particularly to both:

What kind of software development project

Software developers work on three kinds of project:

  1. Developing a complete custom application (more properly called "system development", since the software is only part of the project's end product)

  2. Developing a software product to sell

  3. Developing a reusable software component or family of related components.

Which kind of project is XP aimed at? Based on what XP's promoters tell us in books and articles, we can quickly eliminate two of them:

We conclude, therefore, that XP is intended specifically and exclusively for projects that develop a complete application system for a sponsoring and participating user organization. The case study examples in XP books and presentations confirm this conclusion. It is fair, then, to judge XP on the basis of how well it serves complete application system development.

The big flaw

Make or buy?

Until the 1970s nearly every application system was built from custom-developed software components. Either the organization's in-house developers or an outside contract development firm built software specifically for the sponsoring end users.

For the past two or three decades, however, a steadily growing share of application systems are built largely from packaged program products. Indeed, many organizations have adopted a policy like this:

We will develop application programs only when it can be
shown that no existing program product meets our needs.

That's no longer a variant approach; it is now the established mainstream of application system development.

When and how does the project decide?

Before an organization can evaluate the suitability of any candidate application software products, it must have a clear idea of the problem(s) the product is to solve. Therefore, the best system-development life-cycle (SDLC) methodologies call for systems analysts to determine and document detailed user requirements before any candidate products are considered.2 Obviously that's also before project-team programmers write any permanent code, although user-interface prototypes may be useful in eliciting user participation.

XP not only rejects capturing complete requirements, but also repudiates the whole phased life-cycle concept. It appears, therefore, that XP applies only to those projects where we're somehow certain in advance that we're not going to buy packaged application software. Since such projects rarely arise in typical business or scientific application areas, we conclude that XP is seriously flawed for exactly the kind of project it claims to support.

Scrumtious follow up
July, 2012

A decade ago we expressed concern about the flaws and missing capabilities in the then-new agile methodologies. "Don't worry," replied the agilists, "we're working on just those issues and expect to have a practical solution soon."

A couple of weeks ago I sat through one of those webinar presentations aimed at convincing us of the practical benefits we might gain by embracing the new Scrum version of the agile approach. After a few minutes it was obvious that no progress whatever has been made over the past dozen years in filling the very serious agile gaps. I posted a question about that, which remained unanswered when I gave up after an hour.

Not a freeze

Those who oppose capturing complete requirements point out, correctly, that we can never freeze the specification of a new system or of any non-trivial software component. Indeed changes in the real-world environment as well as new insights on the part of both sponsoring users and developers inevitably lead to changes in the original specifications.

That's fine and expected. It's no excuse, however, for not even trying to describe what we're going to build before we start building it. As changes come to light, we assess their impact on schedule, cost, and usability, and make rational decisions whether and when to incorporate them.

Related issues

Other methodologies exhibiting the same serious flaw

I recently attended a presentation on the Rational Unified Process® (RUP)3, a life-cycle adjunct to the Unified Modeling Language (UML). Like XP, RUP rejects capturing a complete requirements specification in favor of an iterative incremental approach.

The speaker admitted, in response to a question, that RUP simply doesn't handle projects that may lead to packaged software product acquisition. He explained that this is a known shortcoming, and that we can expect a future RUP enhancement to correct it.

That's easier said than done. I believe such an enhancement would require a major overhaul of RUP, which calls for an Elaboration phase that so thoroughly confuses analysis and design that an RUP project would never get a chance to review and approve external specifications even if they managed to capture them.

Of course RUP is only one of many recent methodologies that repudiate capturing requirements. I single it out only because it's drawing attention worldwide and gaining adherents because of its connection with UML, which has been blessed as a "standard" by the Object Management Group (OMG).

A number of XP-like approaches to programming are now promoted as agile methodologies, where "agile" is a euphemism for undisciplined. Although some of them offer useful features, adopting them requires that you commit to custom software development for every project.


1 -- Most of the XP insiders come from a Smalltalk® development background. Their perceptions, therefore, are colored by the kinds of software for which the Smalltalk programming language is well suited.

2 -- Of course, we know of projects that have been launched for the specific purpose of installing and implementing a particular program product, with little or no basis in explicit requirements documentation. We also know that many, if not most, of those projects turn out to be costly fiascos.

3 -- A proprietary life-cycle methodology from Rational Software Corporation.

Return to IDI home page

Last modified July, 2012