Programming continues to refuse to be engineering. This is why there are so many cancelled projects, cost and time overruns and customer dissatisfaction. Planning Extreme Programming offers a way to run small-to-medium size programming projects in such a way as to produce the required product on time and to budget.

To achieve this the authors focus away from complex, report-led planning to a people-oriented process which treats programming like a craft project. Extreme Programming starts by recognising reality: start right and you'll finish right. In fact the authors specifically argue against overtime, increasing manpower on late projects and other such attempts to increase productivity as evidence of failure. They start by breaking projects into stories (or features), insist on customer involvement, iterate relentlessly over a timescale of weeks, set short-term targets based on the evidence of previous iterations and--in a break with traditional practices--absolutely insist on customer involvement at every stage, including signing off each story.

The claimed results of applying the XP approach is a better product with fewer bugs as well as the ability to meet agreed deadlines and budgets. Pretty impressive claims for a book that reads like a set of obvious, common-sense rules. Astonishingly, the only planning tool required is a box of index cards and the right attitude. You are even recommended to avoid spreadsheets. Perhaps, then, the real success of Extreme Programming rests on its implicit acknowledgement that programming is a craft, and not engineering. What can you say? It works. Read it and then implement it. -- Steve Patient