More productive in pairs
A COMMON cause of disaster in software development is that the end product is precisely what the customer originally ordered. In a world moving at Internet speed, a customer's objectives are constantly being revised, so programmers have to be able to hit a moving target. Is there any formula for coping with this sort of unpredictability? With this in mind, 17 leading software gurus holed up in a Utah ski resort last February to produce a “Manifesto for Agile Software Development”. Portentous as it may sound, the manifesto represents the distillation of several successful team-oriented techniques, and should inspire innovation groups outside the confines of software development.
There is a long history of complex methodologies for structuring software-projects. Some seem as intricate and unfathomable as the lines of arcane code that programmers spend their lives writing. Indeed, some computer languages, such as the Unified Modelling Language (see article), have been developed specifically to help programmers do their jobs. But the punishing pace of web-based development has also given birth to a host of more flexible methodologies that deal with the real-world challenge of getting a bunch of wayward nerds to collaborate on getting a product out of the door.
Several of these methodologies were represented at the Utah meeting by their original developers or key proponents. One example is “Scrum”, an approach to project management which focuses on the team that is working out what are the main roadblocks in a project. Feature Driven Development, another popular approach, contrasts with Scrum by defining the main features that a software product must have, prioritising them and then working doggedly through the list.
Extreme Programming (XP), currently the most popular methodology, uses techniques such as pair-programming, in which one person programs while a partner checks the result for bugs and makes sure that only essential code is produced. Another agile approach is embodied in a set of customised tools called “Crystal” which recognise from the outset that each project is unique, and depends on the size of the team and how critical the application is. Developing a web browser, for instance, is vastly different from writing a control system for a nuclear power plant. So development strategies need to reflect this.
Many other agile approaches exist. Common to all is an increased emphasis on personal communication and programmer morale
Many other agile approaches exist, some so new they even lack names. Common to all is an increased emphasis on personal communication and programmer morale, rather than a reliance on careful documentation of written code that characterises traditional methodologies. While this ensures that a team spirit develops, it can infuriate the brilliant loners who like “to pull all-nighters” as they code software idiosyncratically in solitary confinement for 24 hours or more at a time. But a frustrated diva is considered a small price to pay for ensuring that the code remains relevant to the customer's changing needs.
All the manifesto's signatories believe in rapid and frequent releases of partial solutions, so the customer can react along the way to a final product. Indeed, a key feature of being agile is to integrate the customer into team discussions. What agile programmers do not believe in are “virtual teams” where programmers never meet face to face, or off-shore development where detailed product design is done in, say, France, and the nitty-gritty programming outsourced to India. Although such approaches can work for certain applications and may be cheaper, they work badly for complex, shifting tasks.
Some of the catch-phrases and jargon of the agile movement—“individuals and interactions over processes and tools” and “customer collaboration over contract negotiation”—are frowned on by more traditional programmers. However, hard evidence is mounting to support the anecdotal view that being agile is indeed smarter. Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs. Since testing and debugging are often many times more costly than initial programming, this is an impressive result.
In some ways, the software world is a latecomer to the notion of a team-based innovation that is both extremely responsive and highly adaptive
In some ways, the software world is a latecomer to the notion of a team-based innovation that is both extremely responsive and highly adaptive. Similar agile concepts have been around in manufacturing for years. Ironically, nothing in recent times has come as close to demanding total agility as the blistering pace of developing products for the Internet. The explanation may be that the rigorous, logical mindset of people who are used to communicating with computers is not fertile ground for the social values espoused by the agilists.
If so, the manifesto's authors are determined to help spread the gospel. They have formed an “Agile Alliance” which, although little more than a loose network of believers for now, is already having an impact. The first proselytising articles by self-appointed agilists came out in the heavyweight software publications during the summer, and a follow-up meeting of the alliance is planned for October. Meanwhile, the first book on agile software development, written by Alistair Cockburn, who is one of the alliance members, should be in print by then.
All the elements of an intellectual bandwagon would seem to be in place. Those aboard the agile movement are insisting that it should not become another carved-in-stone methodology like XP. And while they agree on what makes good teamwork, they say there is—and always will be—plenty of room for differences of opinion about the tactics to be used. “The unifying objective,” they say, “is to avoid becoming a unified object.” In this, the agilists are, at least, moving in their own nimble and flexible way.
|Copyright © 2001 The
Economist Newspaper and The Economist Group. All rights