Extreme Programming

Eric Jaworski

Extreme Programming

Extreme Programming, also known as XP, is a methodology of software development founded on the belief that teamwork is vital in software engineering and mainly characterized by working on very small increments of code at a time. It was originally introduced in 1996, and gained popularity in the next decade[1].



Essentially, Extreme Programming is a software development model where team members undergo very fast cycles of receiving requirements/problems to solve, breaking them down into simple tasks, and coding them. After coding, the Extreme Programming team will integrate the code from the current cycle into whatever code they previously wrote and will release the updated product. The customer will then evaluate the product and create new requirements for the team to work on[2].


Extreme Programming sounds very similar to the Spiral Model, but what sets XP apart and shapes it as a whole is a set of practices that all of the programmers on the project team follow throughout software development. The main practices are as follows:

  1. Metaphor. Each final/desired product should be able to be defined by a simple metaphor explaining how the system works. For example, when creating a payroll system for Chrysler, the development team (using XP) used the metaphor that the payroll system was like an assembly line, because hour parts were converted to dollar parts, those parts were assembled, and the paycheck was produced at the end of the line[1].

  2. Collective Code Ownership. No single member on an Extreme Programming team owns any part of the code. Once a team member enters their code into the teams collective code base, the code is owned by all of the team members together. Therefore, any team member has the right to edit any code in the code base without asking for permission from anyone, allowing work to proceed much smoother[1].

  3. Pair Programming. Within the development team, programmers always work on a task in groups of two. Whether it is a design, algorithm, or test, this allows the programmers to check each others work. Many times while programming, a persons partner will be able to find a flaw in their code much more easily than the original coder would have been able to by themself, so working in pairs expedites the process of catching coding errors[1].

  4. pair
  5. Incremental Planning. The requirements created by the customer are recorded on story cards and assigned priorities. These story cards are written in natural, informal language, and are given time estimates by the developers. The cards are not organized by their relationships or dependencies, and the customers choose which requirement they want the team to work on. After the deliverable for that requirement is finished, in increments of about a month, the customer will test and examine it, and then choose another[1].

  6. Simple Design. For Extreme Programming, simple designs are best. Only enough design to meet the current requirements should be carried out, and no more. There is no need for pro- grammers to design a more complicated way because they think it will make it easier to meet future needs[2].

  7. Continuous Integration. Larger requirements/assignments are subdivided into small tasks, which should only take about one day. After each task is finished, it is integrated into the collective code base[2].

  8. Refactoring. XP also emphasizes constantly refactoring, which is improving the structure of the code without changing the function. For example, two similar functions could be refactored into one shared function[1].

  9. On-site Customer. A representative of the customer should be on-site with the development team at all times. With XP, the customer actively works as part of the development team, validating or clarifying requirements throughout the process[2].

  10. Coding Standard. Because the programmers have a collective code base that they all share, a coding standard should be followed. This is a set of programming styles or conventions that the programmers agree to follow, in order to make it much easier for one member to understand another team members code[1].

  11. Sustainable Pace. Programmers should not overwork themselves, as too much overtime work is detrimental to code quality and productivity[2].

  12. Small Releases. The Extreme Programming team releases its updated product in short intervals, generally less than a month. This makes Extreme Programming similar to the Spiral Model, as after each release, the customer examines the product for any defects and adjusts future requirements, before the programming team begins work on the next update[2].

  13. Open Workspace. The workspace of the team should be open. There should be central or shared areas that can facilitate open communication both between team members and between a developer and customer. This helps ensure that the development team is meeting the customers requirements, and allows team members to collaborate effectively[1].

  14. Unit Testing. Automated white box test cases are written and added to the collective code base before production code is produced. White box tests are those where a programmer enters an input and compares the output to the programs expected output. They allow programmers to test the logic and structure of the code, and test various paths inside a program[3]. Before a programmer integrates code into the collective code base, that code must pass all of the test cases that have been added to the code base, including those written by other team members. This not only makes sure that the new code being integrated will perform its intended function, but also ensures that it will not break anyone elses code[1].

  15. unittesting

In summary, there are several principal values of Extreme Programming. There should be small, frequent system releases. Customers should be fully engaged and involved with the team. The role of people is emphasized, with pair programming, collective code ownership, and avoiding overtime work. Finally, code should be simple and constantly refactored[2].


Applications of Extreme Programming

Extreme Programming is well-suited for small-to-medium sized projects because of its fast methods. If there is a small team that can work at a common location, XP allows for them to eliminate unproductive activities and focus on coding, saving time and money for companies. It is also well-suited for projects with dynamically changing software requirements, because its releases occur in such small intervals. If a customer is not completely sure what they want the final form of the product to be, Extreme Programming allows them to figure it out through working on the project with the team. There are also many other advantages to Extreme Programming that make its use viable[4].

Through many of its practices, such as collective code ownership and a coding standard, Extreme Programming promotes and produces good teamwork. Good teamwork allows for faster progress overall, as multiple people can work on different parts of a project at the same time, and a more consistent product. Teamwork also increases the quality of the code, as it is always being checked by someone else, and increases employee satisfaction and retention, as employees never feel alone[2].

Extreme Programming emphasizes a strong final product that meets customer requirements. Because the customer is on-site and able to give clarification on requirements whenever necessary, the end product should be exactly what the customer desired, and it reduces the possibility of project failure[2].

The entire process of Extreme Programming moves steadily forwards. Developers are able to determine what they will accomplish in a timespan, and constantly show concrete progress toward the final product. This helps ensure that no time is wasted and work is always being done[2].

One study[5] aimed to find whether Extreme Programming techniques or general team attributes (such as workload sharing, cooperation, or morale) were more important to a teams success. In the study, researchers examined 40 small-scale software development teams that were using Extreme Programming. They measured how closely they followed XP methods, their use of XP team practices, the quality of the programming team, and the quality of the projects outcomes.

The study concluded that certain XP practices were essential to the success of a project. In particular, team factors such as continuous integration, coding standards, and collective code ownership were the most important, as they ensured teammates were able to work with one another. The study also found that planning, on-site customers, and small releases were very important. Out of general team attributes, only cooperation was found to be significant[5].

However, the same study also found that several Extreme Programming practices were actually detrimental to a projects success. That is, there was a negative correlation between the usage of these techniques and the quality of the final product. These techniques were unit testing, pair programming, and refactoring, categorized as foundations. Combined with other findings, one theory to explain this result is that as the craftsmanship of a programming team increases, the more following foundations limits the results of their work. This leads to the conclusion that XP methods are not perfect and are not all beneficial to a development team. However, the study admits that the benefits of these foundations could emerge after delivery, in advantages for the user, such as having fast runtimes even with poor internet connection, which they did not examine[5].

Besides the possible lack of effectiveness of those techniques, there are also other weaknesses in the Extreme Programming model of software development. It is difficult to use XP for large projects that require extensive amounts of documentation, as teams following Extreme Programming typically do not use much documentation. Because all team members are often on-site with one another, they tend to solve problems through conversations rather than documented discussions. Also, one team member may encounter a bug in his code, and without documentation, other team members may create similar bugs in the future[2].

Programmers who use Extreme Programming must be skilled and have experience coding. If the team has inadequate programmers, too much time will be spent trying to figure out how to solve a problem with code, and it will take too long to finish a task. Without skill, XP could cause a software development to degenerate into code-and-fix[2].

The XP practice of programming in pairs is very costly, as it requires the time and pay for two programmers to perform one task, while a single skilled programmer may have been able to complete the task by themself in the same amount of time. Also, not every programmer knows how to create test cases for code; it may be hard to find a programmer who specializes in constructing test cases, which is an important aspect of Extreme Programming[2].

Finally, if the development team is separated geographically, Extreme Programming is often not viable, as it relies heavily on on-site communication and teamwork, both between team members and with the customer. However, for the majority of small software projects, as long as a company has a skilled development team, Extreme Programming is a viable option.


  1. Ruparelia, N., 2010. Software development lifecycle models. URL https://www.researchgate.net/publication/- 220631422. Accessed: 2019-01-19.
  2. Munassar, N. M. A., and Govardhan, A., 2010. A comparison between five models of software engineering. URL http://citeseerx.ist.psu.edu/viewdoc/download?doi=
  3. Williams, L. White-box testing. URL https://students.cs.byu.edu/ cs340ta/winter2019/readings/WhiteBox.pdf.
  4. Fojtik, R., 2011. “Extreme programming in development of specific software”. Procedia Computer Science, 3, pp. 1464 – 1468. World Conference on Information Technology.
  5. Wood, S., Michaelides, G., and Thomson, C., 2013. “Successful extreme programming: Fidelity to the methodology or good teamworking?”. Information and Software Technology, 55(4), pp. 660 – 672. URL http://www.sciencedirect.com/science/article- /pii/S0950584912002091.