Extreme programming

Extreme Programming (XP) is a method or approach to software engineering and the most popular of several agile software development methodologies. It was formulated by Kent Beck, Ward Cunningham, and Ron Jeffries. Kent Beck wrote the first book on the topic, Extreme programming explained: Embrace change, published in 1999. The second edition of the book, which appeared in 2005, delves more into the philosophy of Extreme Programming and describes it as being:

• a mechanism for social change
• a style of development
• a path to improvement
• an attempt to reconcile humanity and productivity
• a software development discipline

The twelve key features of XP, outlined below in Beck’s words, are:

The Planning Game 

Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes, update the plan.

Small Releases 

Put a simple system into production quickly, then release new versions on a very short cycle.

Metaphor 

Guide all development with a simple shared story of how the whole system works.

Simple Design 

The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.

Testing 

Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests indicating theat features are finished.

Refactoring 

Programmers restructure the system without changing its behaviour to remove duplication, improve communication, simplify, or add flexibility.

Pair Programming 

All production code is written with two programmers at one workstation.

Collective Ownership 

Anyone can change code anywhere in the system at any time.

Continuous Integration 

Integrate and build the system many times a day, every time a task is completed.

40-hour Week 

Work no more than 40 hours a week as a rule. Never allow overtime for the second week in a row.

On-site Customer 

Include a real, live customer on the team, available full-time to answer questions.

Coding Standards 

Programmers write all code in accordance with rules emphasizing communication throughout the code.

These ideas are not new. They have been tried before and there have been many reports of failure. The point of XP is that, taken together, these techniques do constitute a workable methodology.

Objections and Justifications

We will consider each point in turn, explaining it briefly, pointing out its disadvantages, and then showing how it works in the context of XP.

The Planning Game

Description

The plan tells you what to do during the next few days. It is not detailed, and it can be changed as required. It can also be changed by either the customer or developers, depending on the situation.

Drawbacks

A rough plan is not a sufficient basis for development. Constantly updating the plan would take too long and would upset customers.

Why it works in XP

The clients can update the plan themselves, using estimates provided by the programmers. The plan is sufficient to give the clients a vision of what you can achieve. Short releases will reveal defects in the plan. A client who is working with the team can spot potential for changes and improvements. Kent Beck compares planning to driving. If you want to drive along a straight road, you don’t carefully point the car in the right direction and then drive with your eyes closed. Instead, you point the car roughly in the right direction and then make small corrections as you go.

Small Releases

Description

A release is a working version of the software. Between releases, the software may be in an inconsistent state. “Small” releases mean obtaining a working version every week, or every month, rather than every six months, or every year. (Cf. Microsoft’s daily builds.)

Drawbacks

Small releases mean that too much time is spent on getting the release to work.

Why it works in XP

Planning focuses attention on the most important parts of the system, so even small releases are useful to clients. With continuous integration, assembling a release does not take much effort. Frequent testing reduces the defect rate and release testing time. The design is simple but may be elaborated later. Any XP project starts with two programmers working on the first release. This pair generates enough work for a second pair to start, and so on.

Metaphor

Description

The metaphor is a “story” about the system. It provides a framework for discussing the system and deciding whether features are appropriate. A well-known example of a metaphor is the Xerox “desk-top” metaphor for user-interface design. Another is the “spread sheet” metaphor for accounting. Game are their own metaphor: knowledge of the game helps to define the program.

Drawbacks

A metaphor doesn’t have enough detail. It might be misleading or even wrong.

Why it works in XP

There is quick feedback from real code to support the metaphor. Clients know the metaphor and can use it as a basis for discussion. Frequent refactoring means that you understand the practical implications of the metaphor.

Simple Design

Description

A simple design is an outline for a small software component. It has the smallest number of features that meet the requirements of the current phase. As simple as possible, but not simpler — Einstein.

Drawbacks

A simple design may have faults and omissions. Implementing the design might bring unanticipated problems to light. Components with simple designs might not integrate correctly into the system.

Why it works in XP

Refactoring allows you to correct design errors and omissions. The metaphor helps to keep the design process on track. Pair programming helps to avoid silly mistakes and to anticipate design problems.

Testing

Description

Write large numbers of simple tests. Provide a fully automatic testing process, so that all tests can be run with one click. Write tests before starting to code. Unit tests are automated tests that test the functionality of pieces of the code (e.g. classes, methods). Within XP, unit tests are written before the eventual code is coded. This approach is intended to stimulate the programmer to think about conditions in which his or her code could fail. XP says that the programmer is finished with a certain piece of code when he or she cannot come up with any further condition on which the code may fail.

Drawbacks

There isn’t time to write all those tests. Programmers don’t write tests — testing teams do.

Why it works in XP

If the design is simple, the tests should be simple too. With pair programming, one partner can think of tests while the other is coding. Seeing tests work is good for morale. Clients like seeing tests working. There are many tests and most of them are run automatically. Code that is “obviously correct” is not tested.

Refactoring

Description

Refactoring is making changes to the software so that it conforms to the design, to coding standards, and is simple and elegant. As code is developed, it has a tendency to get messy; refactoring is removing the messiness. Because XP doctrine advocates programming only what is needed today, and implementing it as simply as possible, at times this may result in a system that is stuck. One of the symptoms of this is the need for dual (or multiple) maintenance: functional changes start requiring changes to multiple copies of the same (or similar) code. Another symptom is that changes in one part of the code affect lots of other parts. XP doctrine says that when this occurs, the system is telling you to refactor your code by changing the architecture, making it simpler and more generic.

Drawbacks

Refactoring takes too long and is hard to control (when do you stop?). Refactoring may break a working system.

Why it works in XP

Collective ownership of code makes refactoring easier and more acceptable to programmers. Coding standards reduce the task of refactoring. Pair programming makes refactoring less risky and adventurous. The design is simple. You have a set of tests that you can run at any time during the refactoring process. Continuous integration gives rapid feedback about refactoring problems. You are not over-worked and over-tired and are unlikely to make silly mistakes.

Pair Programming

Description

Pair Programming means that all code is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer, as well as answering questions. Periodically, the pair exchange roles. The pairs are not fixed: it's even recommended that programmers try to mix as much as possible, so that everyone knows what everyone is doing, and everybody can become familiar with the whole system. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership). Pair programming is one of the more controversial features of XP, yet most programmers who have tried it say they like it.

Drawbacks

Pair programming is slow. What if people argue all the time?

Why it works in XP

Coding standards avoid trivial arguments. No one is over-tired or over-worked. Simple design and writing tests together helps to avoid misunderstanding. Both members of the pair are familiar with the metaphor and can discuss their work in its terms. If you don’t like your partner, find someone else. If one partner knows a lot more than the other, the second person learns quickly.

Collective Ownership

Description

The code is owned by the whole team. Anyone can make changes to any part of the system. This contrasts with traditional processes, in which each piece of code is owned by an individual or a small team who has complete control over it and access to it. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it.

Drawbacks

It is very dangerous to have everything potentially changing everywhere! The system would be breaking down all the time. Integration costs would soar.

Why it works in XP

Frequent integration avoids breakdowns. Continuously writing and running tests also avoids breakdowns. Pair programmers are less likely to break code than individual programmers. Coding standards avoid trivial arguments (the “curly bracket wars”). Knowing that other people are reading your code makes you work better. Complex components are simplified as people understand them better.

Continuous Integration

Description

The system is rebuilt very frequently, perhaps several times a day. (Don’t confuse continuous integration with short releases, in which a new version with new features is built.) The new system is tested.

Drawbacks

Integration takes too long to be repeated frequently. Frequent integration increases the chances of accidentally breaking something.

Why it works in XP

Tests are run automatically and quickly, so that errors introduced by integration are detected quickly. Pair programming reduces the number of changed modules that have to be integrated. Refactoring maintains good structure and reduces the chance of conflicts in integration. Simple designs can be built quickly.

40-hour Week

Description

Many software companies require large amounts of overtime: programmers work late in the evening and at weekends. They get over-tired, make silly mistakes. They get irritable, and waste time in petty arguments. The XP policy ensures that no one works too hard. Developers work no more than 40 hours in any one week. If they work overtime this week, they are not allowed to work overtime next week.

Drawbacks

40 hours a week is often not enough to obtain the productivity required for competitive software.

Why it works in XP

Good planning increases the value per hour of the work performed; there is less wasted time. Planning and testing reduces the frequency of unexpected surprises. XP as a whole helps you to work rapidly and efficiently.

On-site Customer

Description

A representative of the client’s company works at the developer’s site all the time. (This may not be feasible if the client is very small, e.g., a one-person company.) The client is available all the time to consult with developers and monitor the development of the software.

Drawbacks

The representative would be more valuable working at the client’s company.

Why it works in XP

Clients can contribute, e.g., by writing and commenting on tests. Rapid feedback for programmer questions is valuable.

Coding Standards

Description

All code written must follow defined conventions for layout, variable names, file structure, documentation, etc. Note that this is a local standard, not a standard defined by XP.

Drawbacks

Programmers are individualists and refuse to be told how to write their code. Why it works in XP: The XP process makes them proud to be on a winning team.

Assessment

Kent Beck estimates there are between 500 and 1500 XP projects in progress now. Opponents believe there are fewer: Craig Larman says that the only XP processes are those that Beck supervises. The problem is that some groups pick a subset of the twelve features of XP and claim that they are “doing XP”, whereas Beck’s viewpoint is that XP consists of applying all twelve features on a project. XP is an appropriate paradigm for small and medium projects. It has not been tried with teams of more than about 60 programmers and it is not clear that it would succeed at this scale. Nevertheless, XP contains a lot of good ideas and a lot of good psychology. XP assumes that people are most productive if they are doing high-quality work and are not over-worked. XP recognizes that documentation can be a liability rather than an asset.

References

• Peter Grogono's course notes, SOEN341, Fall 2001.
• Wikipedia:Extreme programming
• Kent Beck. Extreme programming explained: Embrace change, Addison-Wesley, ISBN 0201616416
• Kent Beck and Martin Fowler. Planning Extreme Programming, Addison-Wesley, ISBN 0201710919
• Martin Fowler. Refactoring: Improving the Design of Existing Code, Addison-Wesley, ISBN 0201485672
• Ken Auer and Roy Miller. Extreme Programming Applied: Playing To Win, Addison-Wesley, ISBN 0201616408
• Ron Jeffries, Ann Anderson and Chet Hendrickson. Extreme Programming Installed, Addison-Wesley, ISBN 0201708426
• Kent Beck. Extreme programming explained: Embrace change, Second Edition, Addison-Wesley, ISBN 0321278658
• Matt Stephens and Doug Rosenberg. Extreme Programming Refactored: The Case Against XP, Apress, ISBN 1590590961
• Alistair Cockburn. Agile Software Development, Addison-Wesley, ISBN 0201699699