Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
Other elements of extreme programming include programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer’s requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to “extreme” levels. As an example, code reviews are considered a beneficial practice; taken to the extreme, code can be reviewed continuously, i.e. the practice of pair programming.
The strengths of XP include but are not limited to the following:
- Very responsive to changes
- High priority features are developed first
- Pair programming enhances creativity
Possible weaknesses of XP include:
- Large amounts of overhead may be required.
- The order of feature importance can be subjective.
- XP should not be used on a project with a very large staff.
XP was developed to address the issues associated with project risk. XP practices were established to mitigate risk and increase the probability of success. XP was developed for small groups of developers (i.e., between 2 and 12). Risky project types that are good candidates for XP include but are not limited to the following:
- The customer needs a new system by a certain date.
- A new system is a big challenge for the software industry as a whole.
- A new system is a challenge for a company’s internal software group.
XP was developed by Ken Beck, a software engineer, during the 1990s. XP was created to be a software development discipline used to create high- quality software more productively. Scrum and XP are methods that use iterations, however, Scrum iterations last two to four weeks and XP iterations last for one to two weeks. XP is very strict with working in priority order, however, Scrum developers have decision making authority to determine how backlog items will be turned into tasks. Lastly, Scrum can be used with large teams, but XP teams need to be small so that they can operate efficiently and effectively.
XP Core Values
The core values for XP include the following:
- The development team does only what is required and nothing more. This keeps things simple and value is maximized.
- The development team communicates face to face on a daily basis.
- The team uses all iterations to deliver working software on a frequent basis.
- Team members are truthful when discussing progress and estimates.
- Everyone gives and receives respect on the team. Everyone is valued as a team member.
A new value, respect, was added in the second edition of Extreme Programming Explained. Those five values are described below.
Communication – Building software systems requires 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.
Simplicity – Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the “You aren’t gonna need it” (YAGNI) approach. A simple design with a very simple code could be easily understood by most programmers in the team.
Courage – Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary.
Respect – The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.
Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. This value is dependent upon the other values, and is oriented toward teamwork.
XP Principles
The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.
Feedback – Extreme programming sees feedback as most useful if it is done frequently and promptly. It stresses that minimal delay between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations.
Assuming simplicity – This is about treating every problem as if its solution were “extremely simple”. Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas.
The advocates of extreme programming say that making big changes all at once does not work. Extreme programming applies incremental changes: for example, a system might have small releases every three weeks. When many little steps are made, the customer has more control over the development process and the system that is being developed.
Embracing change – The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer’s requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration.
