|
http://www.spinellis.gr/pubs/Breview/2000-IEEE-XP/html/review.html This is an HTML rendering of a working paper draft that led to a publication. The publication should always be cited in preference to this draft using the following reference:
|
Diomidis Spinellis
University of the Aegean, GR-83200 Karlovasi, Greece
email: dspin@aegean.gr
Many software projects face vague and changing requirements, a pressing time schedule, stringent quality objectives, high staff turnover rates, and demands to deliver value at a low cost. Extreme programming (XP) challenges a number of conventional software engineering doctrines and, turning development on its head, offers a lightweight methodology for effectively delivering software while controlling time, cost, quality, and, refreshingly, the project's scope.
Many important aspects of XP can be found by observing XP development in action. Programming is performed in pairs, tests drive development, system design evolves while coding, and integration is performed at least daily. Important aspects of development like code reviews, testing, design, and integration are taken to their extreme level giving the methodology its name.
The theoretical basis for XP is an options-based pricing model of software development. As software is developed in an environment where technological, business, and human risk abounds, investing for the future through careful architectural design, elaborate code structures that will support all possible future requirements, and producing matching documentation can be a waste of effort. Changing requirements or technology may render parts of the system obsolete; design and coding energy expended in those parts will have been wasted. Kent Beck's insight lies in discounting elaborate design for future needs in favor of today's simplicity. Big and important design decisions are deferred until a particular feature is needed. Most important features are developed first, rapidly providing the customer with the functionality required and minimizing the risk of total project failure. As code evolves it can always be refactored in response to new needs. Surprisingly, Beck takes for granted that current technology state-of-the-art and programmer skills will not stand in the way of these continuous design changes.
XP takes a holistic, value-driven view of the development process. Communication in all its forms is important and many XP practices provide opportunities for it to occur. Simplicity is achieved by developing only the functionality needed and planning to change design to accommodate new features. One additional value, feedback, is catered for by creating automated tests before writing code, running tests after design changes or integration, having a customer representative on site, and by rapidly delivering to the customer a system with the most important features implemented. Finally, courage complements the other three values by providing team members the freedom to throw code away or improve system-level design and managers to embrace change. Under XP decisions between different options take into account its basic principles: rapid provision of feedback, development in incremental changes, embracing change, and performing quality work.
XP is defined by a number of important practices working in synergy. A planning phase is used to determine the scope of the next release by combining business priorities with technical estimates (XP clearly defines separate business and development responsibilities). New releases created in a very short cycle coupled by unit tests written by programmers before coding activities, functional tests written by the (on-site) customer, and rapid and continuous integration provide feedback during development. A simple design evolving through constant refactoring, guided by a suitable metaphor, and implemented in accordance to common coding standards obviates the need for extensive documentation. Finally, developers working in pairs on a single machine, collectively owning all the code, providing their own estimates on development time, and working as a rule a 40-hour week make a productive, communicating team. Beck devotes separate chapters to management, planning, development, design, and testing; however, a number of practical implementation aspects are not discussed in depth. A complete case study would help the reader understand how a large project is planned, the pragmatics of pair programming, and, most importantly, how unit and functional tests evolve in a large or GUI-based system. Although it appears that the use object-oriented technology (including object-oriented databases) is implicitly taken for granted when discussing design refactoring, this important implementation constraint and its implications is not given the attention it deserves.
In the third part of the book, Beck offers advice on how to adopt XP (by gradually implementing XP practices), how to retrofit XP into existing projects (with difficulty, but it can be done), outlines the lifecycle of an XP project, people roles, problems, limitations, and exploitation issues. The limitations of XP are frankly admitted; skeptical readers should probably read this chapter first to avoid getting distracted by trying to apply XP to areas where it is not suited for. The author advises against using XP in an environment whose culture would not tolerate it, in large teams (a 10 person team is probably the upper limit), applications where changes incur large overheads, in systems with long compile or test cycles, applications that do not allow easy testing, and in physical environments that separate people (XP teams are encouraged to work cooperatively in a single room; it is unclear how constant interruptions and pair working allow deliberate concentration). Skeptical readers are also encouraged to read early-on the penultimate chapter describing how XP can be applied to existing contractual work practices - albeit not in an open-source development. Although not always entirely convincing, Beck proposes how fixed price, outsourcing, and time and materials contracts can be adopted towards XP (not the either way around). An eclectic annotated bibliography which will doubtlessly provide incentives for more reading, a glossary, and an index (with too many second-level entries and too few first level ones) complement a generally well structured and written book.
XP is clearly not for everyone. However, most projects currently being developed under the pressures of "Internet time" can surely benefit from its approach, and they are not the only candidates. I have often found myself programming following parts of the XP approach; I am glad that Beck formalized the approach into one coherent methodology encompassing the complete software lifecycle. I will certainly try to experiment with XP in a team development context, and I am sure I will not be alone.
Kent Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Longman, Inc. 2000. ISBN 0-201-61641-6, $29.95 US
