Extreme programming (1998)
The basics​
Extreme programming (XP) is a software development methodology that optimizes the software development process by creating good quality programs while considering frequently shifting end-user demands. The process focuses on shorter development cycles to enhance overall software productivity and establishes crucial checkpoints while adapting to new customer requirements.
Software engineer Kent Beck first introduced extreme programming in the 1990s. The XP concept was outlined back then to enable developers to write high-quality software quickly and efficiently by adapting to the changing needs of end users. The methodology reveals engineering practices that allow developers to perform routine tasks beyond their capabilities. That is why the framework is titled ‘extreme’ programming.
Extreme programming seeks the involvement of customers in the development process. Such a practice allows companies to zero in on users’ essential features and minimizes risks by channelling resources in the desired direction. Under extreme programming, customers provide regular feedback on the system. XP also promotes collaborative work, allowing team members to work jointly on one activity or a software project to make it a success and boost productivity.
Extreme programming follows the incremental approach to building products by using continual testing and revision methods. It simplifies development tasks and speeds up the launch of a new product in the market. It makes the coding process efficient and effective, giving customers’ demands importance and value. In short, XP delivers software as and when needed rather than delivering everything simultaneously.
XP shares key Agile principles such as end-user involvement in development tasks, good communication between team members, and iterative development cycles.
You can learn more about Extreme programming by reading the guide at www.extremeprogramming.org.
Pros and cons​
Some of the good things about XP include the following:
Customer-centric. Extreme programming (XP) proposed an iterative development process like Scrum. Still, it encourages planning even less and focuses on getting high customer involvement throughout the development process, which can be considered a form of "discovery".
Short feedback loops. XP recommends a series of practices reinforcing the idea of getting feedback as soon as possible during the development process.
Discovery through spikes. XP approaches estimation more realistically than Scrum by assuming that requirements can change at any given moment and reinforcing the idea of experimentation (spikes) as the only way to increase their accuracy.
High code quality. XP tries to reinforce the idea of not sacrificing quality by requiring practices such as test-driven development.
Some of the bad things about XP include the following:
Measures outputs. XP contradicts itself by requiring estimates and iterations instead of a continuous flow of value and measuring velocity. These two practices will likely lead to sacrificing quality in high-pressure situations.
Hard to scale. XP was not designed to scale and works better with small co-located teams.
Too hard to understand for management. XP failed to become as mainstream as Scrum because management teams often interpreted some XP practices (e.g. pair programming or constant customer involvement) as too expensive. Also, XP has a strong focus on engineering practices over management practices, and as a result, it failed to provide management teams with the confidence required for mainstream adoption.