A Self-Referential Safety Net

<< Introduction

XP is like a ring of poisonous snakes, daisy-chained together. All it takes is for one of them to wriggle loose, and you've got a very angry, poisonous snake heading your way.

To quote Kent Beck from Extreme Programming Explained (Chapter 11, in the context of the exponential change cost curve):

"Each of the practices still has the same weaknesses as before, but what if those weaknesses were now made up for by the strengths of other practices? We might be able to get away with doing things simply."

The latter sentiment is admirable, although it could be argued that software development done properly is simple enough already. However, the real problem behind this approach is that XP becomes a high risk proposition. Because each rule only "works" when supported by some other rule, an XP project is like a house of cards (or, if you'll forgive this mixture of analogies, a ring of snakes).

Each snake, or XP rule, can only be made safe by daisy-chaining it to the next rule; and so on:

No detailed written requirements: The project leaps under way without any formalised requirements (just some "user stories" hand-written on story cards), and without a particularly solid idea of where it's going to end up. This is a likely proposition because XP is aimed at "high risk projects with dynamic requirements", and due to XP's promises such a project will likely go ahead, whereas in reality-land the brakes should be slammed on and the project examined to find out how its inherent risks can be lowered before any real expense is committed. Nevertheless, vague and sporadic (sorry, dynamic) requirements are handled by designing as you go along - no big up-front design.

No big up-front design means that little or no time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But this is considered "safe" because the code is being constantly refactored.

Constant refactoring (i.e. constant tweaking and improving of your code) creates an unnecessary overhead. Outside the XP world, occasional refactoring is welcome, as it is useful to check and improve ("de-fluff") your design; but constant refactoring makes no sense. In fact it only makes sense in the XP world, where the design is made up as you go along. Constant refactoring could potentially introduce lots of bugs, as dependent code is broken when you make small insidious changes to your design; but it's considered safe because of extensive unit testing.

Unit tests are useful in everyday coding (not just in XP). However, as a safety net for test-first design and constant refactoring, they leave a critical area uncovered: design correctness. Because XP as a process does not involve getting a design spec reviewed by senior engineers, and instead places the emphasis on a constantly evolving design, this can be a high risk. The problem is that unit tests catch certain types of code-level bug, but they do not catch "wrongness" of a design. To catch design errors, you really need a human to be involved - ideally, a full-time person to sit beside you and behave like a "design unit tester". Luckily, XP has just such a safety net: the pair programmer.

Pair programming is somewhat overrated (for reasons that are explored later in this article); but it's considered safe because the programmers can help each other to stumble and fumble through the dark tunnels of scary Castle Complexity. But the programmers wouldn't know what to code without a specification, so XP gives them a walking, talking, mind-changing spec: the on-site customer.

Having an on-site customer representative is risky, because he/she is bound to be pretty junior. Is the customer really going to spare a senior decision-maker for an entire year? But regardless, the customer representative "becomes" the formalised requirements spec; XP advocates believe that therefore you need no detailed written requirements.

No detailed written requirements are dangerous because ... and we're back at the start of the loop.

"There's a hole in my bucket..."

>> Contracts in XP (Release Plan Optimism)

Why not leave a message on the Software Reality XP Forum?

<< Back to XP Central

<< Back to Lifecycle