Skip to main content

eXtreme Programming (XP)

· 6 min read
Kevin Lee

Originally Posted in another blog of mine on the 3rd of August in 2007.

This post is about my knowledge and understanding of eXtreme Programming (XP) acquired from my study at UTS. In august, 2008, I took the subject named eXtreme Programming as I would like to become a better programmer and developer.

XP is the one most prominent methodology of Agile methodologies. It is, according to Avison and Fitzgerald (2006), used to support quicker development for small and medium size system and application development. They also affirm that XP is more rapid in software development than step-by-step methodology such as waterfall model. In XP, there are often customer meetings to get user requirements and to apply immediately these into the system development, thus it can guarantee the certain level of quality.

There are 4 values of XP which are:

  1. Simplicity
  2. Communication
  3. Feedback
  4. Courage

and 12 practices which are:

  1. The Planning Game
  2. On-site Customer
  3. Small Releases
  4. Simple Design
  5. Pair Programming
  6. Testing - Test First
  7. Refactoring
  8. Collective Ownership
  9. Coding Standards
  10. Continuous Integration
  11. 40 Hour Week
  12. Metaphor

The followings are what I've understood from the lecture.

■ XP Values

  • Simplicity: choosing simple design, and small release can produce the system quickly with satisfying the customers' requirements for the current iteration of the project.
  • Communication: good communication through the pair programming and frequent customer meetings can deliver a good result.
  • Feedback: From testing, customer meetings & stories, pair programming and small timeboxes to repeat project process, enough feedback can be gained to improve the quality of the system.
  • Courage: When it is certain that the changes made by a programmer do not bring about some unexpected problems, the programmer can be confident to refactor and redesign the system to make it better (Testing can be the key of this).

■ XP Practices

  • The Planning Game: At the beginning of the project, customers write what functionalities they want the system to have on the 'story cards' then developers and programmers estimate the time required to make each function, and write it down on each card. After that, the customers choose the cards which have what they want the system to have in one week. Those are probably the most important or essential functions in customers opinion.
  • On-site Customer: The customers are sitting next to the developers, thus the developers can easily ask what the customers really want. As the customers do usually not know what they want at the beginning of the project, but they will know as the project is progressed, their requirements can be changed frequently. If they are near the developers, the developers can easily make conversation with them so it can increase the quality of the system (software). Good communication => High quality software.
  • Small Releases: The software is often released rather than the one final software is released at the end of project. Thus, the customers can know what the software will look like and if it fulfills what they want. The developers can also get the feedback from the customers which can help the developers to make the system as what it should be. It can bring about another benefit. As each time releases working version of software, the developers and customers can, somehow, have the software with the certain functionalities when the project is cancelled.
  • Simple Design: Design the system as simple as possible but works. It can prevent from over-engineering. This can also deliver business value quickly so the customers can get what they want early. In this case, both customers and developers can have more time and money to reconsider what are more required. The developers can always refactor the existing code and simple design can help them to do so, for "simple design" does NOT mean "bed design". It might mean simple to maintain, simple to understand and simple to redesign.
  • Pair Programming: Two programmers share one computer to programme. When they work together, one think tactically about the part of the programme which he/she is about to code whereas the other one thinks strategically about how that part fits into the whole programme. With pair programming, The one can learn from the other one who is more experienced, and vice versa. This practice can cause better communication and feedback, and those can heighten the quality of the software. As both know about the programme they are working on, it can increase truck factor which means reducing the risk of the project failure.
  • Testing - Test First: The tests are created first before starting coding. First with all those tests, the programmers can know what functions they need to make. They can also know whether their programme fulfills the requirements or not. They can code the programme pass each test, and passing all the tests means completion of the software. It can also help to check if any changes, made after the programme is passed the tests, cause any problems or unforeseen results.
  • Refactoring: Refactoring is changing the existing code to improve its design and readability. It can make simple design possible, and can help the programmers easily change the programme as customers require. It is easy to refactor with tests. After refactoring, if the programme is still passed all the tests, it may mean the changes did not break any existing code. (The recommended book to read for refactoring is "Refactoring, Improving the Design of Existing Code" written by Martin Fowler and published by Addison Wesley. ISBN: 9780201485677, $79.95).
  • Collective Ownership: There is no owner of any particular code so anyone can change any code. It can improve productivity and reduce the risk of the truck factor. Tests and coding standard make it possible.
  • Coding Standards: Every programmer follows one agreed coding standard, including indentation, capitalisation, names and so on, can improve speed and help the programmers communicate with each other. They also can focus on the real issues rather than focus on reformatting others' code to make these understandable.
  • Continuous Integration: Team members integrate and test frequently what they made rather than waiting all of them finish the parts assigned and put them all together to test. If they wait until all the members finish coding, they will face many problems to make the programmes work.
  • 40 Hour Week: No overtime! Overtime rather decreases than increases the productivity. I'd like to quote the words from Jason Statham, performing in the movie 'Transporter', which is my favourite. "I can't think straight when I'm tired. After a good night's sleep...I always see things better."
  • Metaphor: Using a simple metaphor to describe what the system is like can help to understand the programme and communicate with it. (Metaphor is probably the least popular XP practice)

※ References

Avison, D., Fitzgerald, G., 2006, Information system development – methodologies, techniques and tools, 4th edn, McGraw – Hill Education, Berkshire

Wells, D. 2001, Extreme Programming: A gentle introduction. viewed 03 August 2007, <http://www.extremeprogramming.org>