Kent Beck
Longman Higher Education, 2000
ISBN 0201616416
Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)
Kent Beck has written one of the most controversial books to hit software engineering in recent years. The Web (especially the Wiki Wiki site at www.c2.com) is buzzing with discussion of user stories, pair programming, and Beck's various maxims. Plainly there is much to think about.
Extreme Programming is, as its name suggests, ostensibly aimed at programmers. However, the ideas advocated in the book go far beyond programming, as the approach brings together users and developers, spanning the whole software life-cycle from initial requirements right through to testing. The approach therefore constitutes a novel look at requirements engineering, among other things.
Extreme Programming Explained provoked a stormy response when it came out. For example, review comments on the Amazon.com website (which also provides descriptions of the book by its publisher and its author) ranged from starry-eyed admiration to virulent attack. Clearly, Beck was presenting a radical approach. Let us try to take a middle road, free of both happytalk and destructive criticism.
XP has four main strands: listening, testing, coding, and designing, in no special order for they all happen in parallel.
Listening means meeting users regularly, and taking down User Stories from them. These form the basis of both coding and testing. User stories are similar to sketchy Use Cases or simple abstract Scenarios. For a discussion of when use cases should be sketchy and when analytic, see Systems Engineering with Use Cases.
Testing means creating executable test scripts even before coding starts. The tests act as precise specifications for small parts of the system's behaviour. The tests are run every day, or more often. The number of defined tests, and the number of them that are passed by the software, measure the project's progress.
Coding means 'the one activity we know we can't do without'. Pairs of programmers work constantly together to create the simplest possible solutions for tasks based on single user stories, or possibly a few related stories at once. The premise is, naturally, that code for later stories will not usually disturb existing code, i.e. that user stories describe separate transactions that can safely be implemented separately.
Designing means going over the code and 'refactoring' it to remove any duplications or inelegant constructs, as well as thinking out what structure is absolutely needed. The premise is that skilled programmers can keep the design sufficiently flexible to avoid getting stuck when an unexpected case arises.
In addition, Beck's book is full of advice and strictures to would-be XP-ers. For instance, work a 40-hour week to stay fresh. Write tests before you code, minute by minute. Preserve these tests forever. These are supported by explanation and often persuasive arguments.
There may be many answers to this, but a key may lie in its radicalism and revolutionary appeal for equality. Programmers work directly with users to specify, design, and test systems, so they answer to no higher authority. There is an intriguing parallel here with The ClueTrain Manifesto.
It also offers a realistic way for users to participate in design, to communicate their requirements directly to developers, and to see that they will be delivered through rigorous testing. This strand is of course part of a wider movement that includes Participative Design, RAD and JAD, and co-operative requirements engineering with use cases/scenarios. XP thus responds to the strongly felt need to ensure that the customers' voices are heard throughout development.
In addition, XP offers immediacy of action for those impatient with the bureaucracy of contracts and written specifications, not to mention the high chances of failure of traditional software projects, as documented by the Standish Corporation and others.
Again, there may be several reasons, but one is surely distaste for anything that has 'extreme' in its title. Another and better reason is that many large systems are critical to business, if not to property and human life. Most of us want to know that the nuclear power station that we fly past - and the aircraft we fly in - were strictly and perhaps formally specified in full before they were designed or tested in similar detail. XP might sound like a step towards the slapdash methods sometimes associated with rapid prototyping approaches, where requirements are scarcely-documented and testing is unknown. Beck's insistence on elegant code and disciplined testing is however far from that.
Where does the truth lie? Readers will have to judge for themselves. Beck is no stylist with the English language; this is a book written with simple directness, and based on several years of experience. Like all experience, it is valid in itself, as far as it goes. Beck does not claim that XP is suitable in all circumstances. What he does argue, passionately, is that it is very good in the circumstances in which he and his colleagues have applied it.
For readers who may imagine that Beck is just another semi-literate programmer with over-enthusiastic ideas, Extreme Programming Explained may come as a surprise. It is well indexed and contains an interesting bibliography. The bibliographic notes and the text itself make it plain that Beck is well read and familiar with his material, and indeed used to arguing points closely in debate.
See also my article on XP for a discussion of the systems and requirements engineering issues raised by Beck's ideas.
This book is compulsory reading for all who want to know the latest ideas about software development, and see for themselves how Beck's approach could change their lives.
Postscript: there is a chapter by Kent Beck and David West in Scenarios, Stories, Use Cases, and the book compares Agile Methods with e.g. the RUP. The controversy continues but perhaps we can start to see some light emerging from the heat.
© Ian Alexander 2000, 2004
You may also like:
