Search

The Online Encyclopedia and Dictionary

 
     
 

Encyclopedia

Dictionary

Quotes

 

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


Contents

XP core practices

The core practices of eXtreme Programming, as described in the first edition of Extreme programming explained can be grouped into four areas (12 practices) as follows:

Fine scale feedback

  • Test driven development
  • Planning game
  • Whole team (was Onsite customer)
  • Pair programming

Continuous process rather than batch

  • Continuous Integration
  • Design Improvement (was Refactor mercilessly)
  • Small Releases

Shared understanding

  • Simple design
  • System metaphor
  • Collective code ownership
  • Coding standard or Coding conventions

Programmer welfare

  • Sustainable pace (original name: Forty hour week)

In the second edition of Extreme programming explained a set of corollary practices are listed in addition to the primary practices.

The core practices are derived from generally accepted best practices, and are taken to extremes:

  • Interaction between developers and customers is good. Therefore, an XP team is supposed to have a customer on site, who specifies and prioritises work for the team, and who can answer questions as soon as they arise.
  • If learning is good, take it to extremes: Reduce the length of development and feedback cycles . Test early.
  • Simple code is more likely to work. Therefore, extreme programmers only write code to meet actual needs at the present time in a project, and go to some lengths to reduce complexity and duplication in their code.
  • If simple code is good, re-write code when it becomes complex.
  • Code reviews are good. Therefore XP programmers work in pairs, sharing one screen and keyboard (which also improves communication) so that all code is reviewed as it is written.
  • Testing code is good. Therefore, in XP, tests are written before the code is written. The code is considered complete when it passes the tests (but then it needs refactoring to remove complexity). The system is periodically, or immediately tested using all pre-existing automated tests to assure that it works. See test-driven development.

It used to be thought that Extreme Programming could only work in small teams of under 12 persons. However, XP has been used successfully on teams of over a hundred developers. It's not that XP doesn't scale, just that few people have tried to scale it, and XPers refuse to speculate on this facet of the process.

XP values

Extreme Programming initially recognized just four values but a new value was added in the second edition of Extreme programming explained. The five values are:

  • Communication
  • Simplicity
  • Feedback (formerly Testing)
  • Courage (formerly Aggressiveness)
  • Respect (the latest value)

Communication

A fundamental task of building software systems is communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation.

Extreme Programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, Extreme Programming favors simple designs, metaphor, collaboration of users and programmers, frequent verbal communication and feedback.

Simplicity

eXtreme Programming encourages starting with the simplest solution and refactoring to better ones. The difference between this approach and more conventional system development methods is the focus is on designing and coding for the needs of today instead of those of tomorrow, next week or next month. The disadvantage is that maybe you have to give more effort tomorrow to change the system but the advantage is that you will not bet on possible requirements of the future and so don’t take any risk on that. Because when you’re coding and designing for uncertain requirements of the future you take a risk by spending resources on something that might not be needed. Related to the previous value, "communication", simplicity in your design and coding will improve the (quality of) communication. By designing and coding your system simple, it is easily understood by every programmer in the team.

Feedback

Within eXtreme Programming, feedback is related to different dimensions of the system development:

  • Feedback from the system: by writing unit tests the programmers have direct feedback from of the state of the system after implementing changes.
  • Feedback from the customer: The functional tests are written by the customer and the testers. They will get concrete feedback about the current state of their system. This review is planned once in every two or three weeks so the customer can easily steer the development.
  • Feedback from the team: When customers come up with new requirements in the planning game the team directly gives an estimation of the time that it will take to implement.

Feedback is closely related communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells you to recode this part. A customer that is able to test the system every three weeks according to the functional requirements (User Stories). To quote Kent Beck, Optimism is an occupational hazard of programming, feedback is the treatment.

Courage

The Extreme Programming doctrine of "Courage in system development" can be best explained by a couple of practices. Simplicity stated that you always design and code for today and not for tomorrow. This may result in you stuck in your design and requiring a lot of effort to implement anything else. Courage says to do a refactoring of the system. This means reviewing what you already have and make it so that future changes can be implemented more easily. Another example is throwing code away. Every programmer is familiar when dealing with a complex piece of programming you get stuck in your own design and coding and you’re working on it all today. When you come back the next day with a clear and fresh view you’ve solved the problem in half an hour.

Respect

Controversial aspects

Extreme Programming also has its share of controversial aspects:

  • Detailed specifications are not created or preserved.
  • Programmers work in pairs.
  • There is no Big Design Up Front . Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Unit-testing is a design discipline .
  • A customer representative is attached to the project.

See also

References

  • 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
  • Alistair Cockburn : Agile Software Development, Addison-Wesley, ISBN 0201699699

External links

Last updated: 08-28-2005 03:38:46
Last updated: 10-29-2005 02:13:46