XP in its gist

The cool people
Various luminaries created The Agile Manifesto as a response to the up-front design's flaws. Their seductive arguments contain much wisdom, gleaned from numerous failed projects.
Observing that requirements change throughout a project, the agile crowd embraces change and welcomes modifications at every phase of the project. The agile crowd believes great programmers make the best team members. Well, duh. But what happens to the less-than-great developers? It's statistically impossible for everyone to be above average. Managers can't ignore the fact that some team members just won't be as awesome as the agile crowd demands.

The agile crowd disses schedules. "Great software takes time; it'll be done when it's done," they say. Though there's much truth in this, real business pressures demand schedules. Sometimes it's geometry that governs deliveries; a narrow window happens only every couple of years in which to launch a spacecraft to Mars. Miss it, and you physically can't deliver the mission for years to come. Less dramatically but just as important is ensuring adequate cash flow: get the product into the market so the company can pay its bills.

The most visible agile method today is eXtreme Programming (XP). Software literature abounds with stories of XP; some 20 books promote the idea. Originated by Kent Beck, enhanced by dozens of others, XP sometimes seems to be taking the software world by storm.

XP's philosophy is that everything changes all of the time. People, tools, requirements, features, and the code are all in a constant state of flux. Instead of trying to immobilize the world, to institute a halt while we generate a project that meets today's specs, XPers embrace and even try to provoke change. Beck believes that software projects work best when guided by many, many small course corrections rather than just a few big ones. As he puts it, "The problem isn't change, per se, because change is going to happen; the problem, rather, is the inability to cope with change when it comes." That's a laudable concept. However, the implementation leaves, in my opinion, much to be desired.

Traditional software engineering attempts to delay coding until the requirements are nailed down. In XP the code is everything. Jump in and start coding today. To quote advocate Ron Jeffries, "Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal—half an hour should be the most time you spend to do this." Then start coding.

Needless to say that's a radical notion, one that frankly terrifies me. Embedded systems usually don't have a Windows Update feature. They've got to be right; in some cases errors can lead to death. Ten minutes of design is not the path to carefully-analyzed software.

XP takes a few software engineering ideas which work, and, as they say, turns the dial up to 10. If code inspections are good (and they are), then inspect constantly. In fact, programmers work in pairs, each pair sharing a single machine. They take turns typing while the other audits.

If tests are good (and they are), then let the tests define functionality. Developers create tests in parallel with their code; no function is done until it passes all of the tests.

If customer interaction is good (and it is), then in XP you may not develop any code unless a customer lives with you, spending 40 hours a week with the team. The on-site customer compensates for the lack of a spec; developers constantly lob questions at this (presumably savant-like) team member.

If bad code should be trashed (and it should), then all code is "refactored" (rewritten) whenever it can be improved, and by any team member, since everyone is responsible for all of the code.

XP is a fascinating and different approach to the problem of developing software. I'm entranced with their test-first, test constantly, and don't-move-on-till-the-tests-pass philosophy. If only most of us practiced such aggressive checking! Refactoring is also a great idea, though I'd argue that we should attempt to write great code from the outset, which minimizes the number of refactorings needed.