Extreme programming (XP) represents a subtype of agile software development and is a software development methodology intended for software quality improvement, as well as increase of responsiveness to customers’ requirements that are constantly changing. It is a pragmatic approach to program development, emphasizing business results first and foremost and taking a get-something-started, incremental approach to developing the product, using continual revision and testing (Poole and Huisman, 2001).
Agile software development unites several software development methodologies that are based on incremental and iterative development, in which solutions and requirements evolve through interaction of cross-functional, self-organizing teams. In other words it can be defined as an iterative and incremental (evolutionary) approach to software development performed in a highly collaborative manner by self-organizing teams within effective governance framework with “just enough” ceremony, producing high-quality software in a timely and cost-effective manner, which meets the changing needs of the stakeholders (Stephens and Rosenberg, 2003).
This type of programming was developed and introduced by Kent Beck while he was working on his C3 project (Chrysler Comprehensive Compensation System). In October 1999 his book on XP was published. Thus, this concept is rather new, but its practices were well-known for a certain period of time before it was introduced (Herela, 2005). This allowed developers to choose the best practices to base the current methodology on them. In the late 1990s and in the beginning of 2000s, XP was widely discussed and adopted in a number of spheres that were quite different from the origins.
In general, the goal of XP was described in the book Extreme Programming explained (Beck, 2005), which is organization of higher quality software production in a productive way. It is aimed at reducing the cost of changes required by the customers by the way of using multiple short development cycles instead of one long. There are commonly distinguished 12 practices, on which XP is founded. They are groups into four categories, which are the following (McBreen, 2002):
1. Fine scale feedback
Pair programming: the code is produced by two people, working on the given task on one workstation.
Planning game: it represents meeting that takes place once per iteration, which is usually once a week.
Test-driven development: unit tests are performed to make sure that the code cannot be broken.
Whole team: team of programmers constantly cooperates with the end users of the program to better understand their needs.
2. Continuous process
Continuous integration: the team is always focused on development of the latest version.
Refactoring or design improvement – when the development process gets stuck, it is necessary to refactor the code, changing the architecture and making it easier.
Small releases: software delivery is performed through multiple releases of live functionality.
3. Shared understanding
Coding standards: set of rules followed by all the team members.
Collective code ownership: everyone is responsible for the code.
Simple design: programmers recognize the “simple is best” approach.
System metaphor: story the team can tell about the way system works.
4. Programmer welfare
Sustainable pace: work of no more than 40 hours per week.
In XP there are four activities regarded as basic, which are performed in the process of software development (Beck and Fowler, 2001):
1. Coding – code is regarded as the most important product, as without it there is no working product. It can be used to find the best solution and to help communicate considerations on different programming problems.
2. Testing – programmers prefer to do a lot of testing to eliminate all the possible mistakes and flaws (Laymana, Williamsa, Damianb, and Bures, 2006). There are two common types of tests – acceptance tests serve to see whether programmers understand the customers’ requirements appropriately; unit tests serve to see whether the given features work as they are supposed to.
3. Listening – programmers should be very attentive when listening to the customers’ requirements so as to understand the business logic.
4. Designing – in order to avoid the risks of making the system too complex and not to fail it, it is necessary to design structure that will organize the system logic.
Today XP depends on five values, although in the beginning there were only four of them. The values are as following:
Simplicity: XP is first of all aimed at simplicity, as programmers consider that it is easy to add extra functionality later. In this way XP differs from many other approaches to programming, where possible needs for future are taken into consideration. XP is developed for the purposes of today, not of tomorrow. This approach is called YAGNI – “You ain’t gonna need it” (Maurer and Martel, 2002).
Courage: it includes several practices, such as the commandment to code always for today instead of for tomorrow, the feeling of comfort when refactoring the code when it is required, knowledge when it is necessary to throw the code away, and overall persistence in what programmers do.
Communication: instead of communication through documentation that is usually practiced by programmers in the other approaches, XP favors and encourages frequent verbal communication between programmers so as to give them a shared view of the system, matching the view of its users (Auer and Miller, 2001).
Respect: applicable to the others and each of the programmers in particular. It is necessary to perform work in away so as not to spoil the work of others or delay it. Everyone in a team in this way feels appreciated and valued. Owing to this, the best results can be achieved.
Feedback: In XP there are three types of feedback: from the system, from the team and the customer. In the first case results of unit and integration test provide the necessary feedback (Astels, Miller, and Novak, 2002). Feedback from the team is received when some changes are necessary to be implemented, as in this case the whole team decides on the time necessary for the changes. When the feedback from customers is considered, we talk about the functional tests aimed at getting concrete feedback.
There can be distinguished the following advantages of XP:
1. The risk for the project is decreased owing to the focus on incremental, small release:
2. Owing to the focus on customers, there is a great chance that their needs will be met.
3. XP is convenient for programmers who are usually unwilling to adopt a software process, enabling organization to manage its software efforts better.
4. The quality of work can be increased by the way of continuous integration and testing.
There can be distinguished the following advantages of XP:
1. It is not proven that XP is effective in work with systems that have scalability issues.
2. XP is geared toward one project, maintained and developed by one team.
3. XP cannot work in such environment when a manager or customer insists on a complete specification before the start of programming.
4. XP is vulnerable to the developers who: think they know everything; don't cooperate well with others; don’t want to share their code.
5. XP cannot work in such environment when programmers are separated geographically.
Bibliography
Astels, D., Miller, G., and Novak, M., 2002. A Practical Guide to eXtreme Programming. Upper Saddle River: Prentice Hall.
Auer, K., and Miller, R., 2001. Extreme Programming Applied: Playing to Win. Boston: Addison-Wesley.
Beck, K., 2005. Extreme Programming Explained: Embrace Change. 2nd ed. Boston: Addison-Wesley.
Beck, K., and Fowler, M., 2001. Planning Extreme Programming. Boston: Addison-Wesley.
Herela, H., 2005. Case Study: The Chrysler Comprehensive Compensation System. [online] Available at:
Laymana, L., Williamsa, L., Damianb, D., and Bures, H., 2006. Essential communication practices for Extreme Programming in a global software development team. Information and Software Technology, 48(9), pp.781-794.
Maurer, F., and Martel, S., 2002. Extreme programming. Rapid development for Web-based applications. Internet Computing, 6(1), pp.86-90.
McBreen, P., 2002. Questioning Extreme Programming. Boston: Addison-Wesley.
Poole, C., and Huisman, J.W., 2001. Using extreme programming in a maintenance environment. Software, 18(6), pp.42-50.
Stephens, M., and Rosenberg, D., 2003. Extreme Programming Refactored: The Case Against XP. Berkeley: Apress L.P.
