Pros and Cons of Extreme Programming

Have you ever encountered a customer with a finalized technical specialization, detailed product description, and a definitive list of software features? Perhaps, you’ve instead faced cases when the requirements have changed in the middle of the development process, and you had to adjust or rewrite the code. Well, such things happen all the time, and that is when extreme programming emerges. 

While working on more than 130 web and application development projects, the Arounda team has tested traditional and agile management approaches, including scrum sprints and kanban charts. Extreme programming is the most radical case of agile software development. This article compares extreme programming (XP) advantages and disadvantages. 

What Is Extreme Programming?

Extreme  Programming (XP) is a software development framework based on an iterative agile approach, test-driven development, and continuous integration and deployment. 

XP was first tested in Chrysler Comprehensive Compensation (C3) project while building a system that had to replace several payroll applications. In the mid-’90s, Kent Beck and Ron Jeffries joined the team to improve software performance. They developed the XP methodology and, in 1997, presented the system that provided payments for around ten thousand people. The C3 system was intended to grow to a bigger scale, but in 1999, the development stopped. 

Several folks from the project wrote books to share their new approach. `Extreme Programming Explained: Embrace Change` by Kent Beck is considered the bible of XP. It states the following fundamentals of extreme programming: 

• Test-First Programming. You usually develop a code, then write tests and run them. But in XP, it works back to front. Failing unit tests are written before programming. The programmer develops the code until it passes the test. Automated tests keep running all the time.  
• Continuous integration and deployment. New units are integrated into the system as soon as they are ready. The whole system gets tested several times a day.
• Pair programming. All software is produced in pairs, two people at one screen. One programmer writes the code, and the other one hunts for errors, reviews the source, and suggests improvements. 
• Simple architecture. The idea is to put the minimal system into work and add needed features and flexibility gradually, while in traditional programming, the system is first designed in all its complexity, and only then the coding starts. 
• Customer requirements priority. Extreme programming is bound to the customer’s requirements even if they change regularly and require dramatic software alteration. XP encourages creativity, courage, and openness in programmers and sees mistakes as a usual part of digital product development.   

Principles Of Extreme Programming

The XP principles take root in values that Kent Beck and his colleagues have put into their new approach: simplicity, communication, feedback, courage, and respect. While the values are abstract, the principles are more practical and show how to make the approach work. 

Extreme programming pros and cons have origins in the five core XP principles.

Rapid Feedback 

Rapid feedback is the main premise of fixing bugs as early as possible. The XP framework is geared toward customer productive critics, testing system logs, daily and weekly meeting conclusions, and permanent feedback from team members. Programmers should correct the code within minutes or hours rather than collecting the bugs in the backlog. The teamwork is split into short cycles to change the software as soon as possible, test, and gather the next feedback portion. 

Assumed Simplicity 

The simplicity value of XP says that programmers should always stick to the simplest solution and eliminate the uncertain complexity that leads to errors. Assumed simplicity shows how to realize this practically following two rules:

• YAGNI (You Ain’t Gonna Need It) - means that you don’t add any additional functionality above requirements and focus on important issues straight away. 
• DRY (Don’t Repeat Yourself) - programmers avoid repetitions of code blocks and write functions instead. If the software has to be changed you only do it once in the function description.   

Incremental Changes 

Traditionally, software companies launch the first product version, then collect feedback and correct mistakes in the next update. In XP, changes happen continuously in small steps. The team doesn’t accumulate corrections of the source for the second version. Instead, they react to negative feedback or system errors instantly as soon as they are detected. 

This principle also applies to changes in design and team structure. Corrections are made as fast as possible but in small incremental steps. DevOps engineers apply this principle as well.     

Embracing Сhange 

The team should be attentive to the clients' criticism and provoke feedback, although it may lead to a program change and even a complete rewrite of the code. It is human nature to stick to the old things even if they don’t match the new situation, but in XP, team members should not stand in the way of change. They should eliminate fear in software development and cultivate creativity and discipline to work with flexible system architecture.  

Quality Work 

Developers face daily conundrum tasks; difficulties and stress often result in lousy code and weak solutions. In the XP framework, the code is continuously tested, the whole team exhanges suggestions and support hourly, and programmers work in pairs. This approach can conquer programmers' fear of not coping with the problem, resulting in closeness and grumpiness. Instead, developers focus on the best possible quality and gain moral satisfaction from the effective orchestra of teamwork. 

In the following two abstracts, we answer the question, ‘What are the pros and cons of extreme programming (XP)?’

Pros Of Extreme Programming

The extreme programming benefits come from the approach. Let’s see what they are.

• Robust software. Continuous testing and test-driven development result in clean code that works now. 
• Fast development. Thanks to the fast pace of incremental change, continuous integration, and deployment, extreme programming last several months, whereas the usual approach would require years. 
• Low cost of change. Rapid feedback and rapid change cost less than major updates. 
• Error avoidance. Pair programming ensures fewer mistakes, fewer rewrites, and stable program units.
• Lean product. Thanks to the YADNI and DRY rules as well as the system metaphor technique, the software is easy to maintain and enhance. The code is clear and readable all the time. 
• Desired Product. ХР is tailored to the customer’s requirements. That is why the end product meets all the demands.  
• Teams` well-being. The vital premise for the XP work is that team has to be motivated and rested. That is why the work is limited to a 40-hour week. 

Cons Of Extreme Programming

The main disadvantages of XP are the following: 

• Lots of effort. XP requires lots of persistence, creativity, and lean thinking to adjust the system to the client’s needs day by day.  
• Customer must participate. According to the XP framework, at least one client representative must work with the team permanently. Very often, customer has no interest and time to do so. 
• Relatively high costs. Pair programming means double salary and can be problematic for smaller teams with a limited budget. XP teams necessarily include a tracker and a coach, which increases expenses. 
• Time for meetings. In extreme programming, meetings occur very often. There are daily stand-ups that last up to 15 minutes, longer end-of-the-week meetings, the Planning Game at the beginning of each development phase, etc. Communicating face to face rather than writing messages or documentation is advisable. Altogether meetings require additional time and nerve. 
• Location restriction. XP projects imply that the customer participates in the development regularly and meets the team face-to-face. This is hard to implement when the customer has a distant location. 
• Stress. There is a lot of stress and pressure due to tight deadlines when the code has to be designed and tested today, not tomorrow. Indeed, this is why the programming is called ‘extreme.’ 

Pros and Cons of Extreme Programming at a Glance

Both benefits and drawbacks have significant weight. Consider them once again before implementing the XP approach. 

Conclusion

There are pros and cons of extreme programming. You may love it or doubt it, but this approach has opened new perspectives to software development. XP is not a magic wand for every project or team, but it works exceptionally well

• when the customer does not have a full picture of the end product.
• when the requirements change dramatically on the go. 
• in case of strict deadlines combined with new technology.
• with a co-located development team of 5 to 12 people. 
• with automated testing technologies. 

One of the breakthrough ideas of Kent Beck is not to force team members to limit themselves to the roles of programmers, testers, architects, analysts, and managers. XP team members participate in all these vital activities every day. 

As the Arounda team consists of multidiscipline specialists in design, engineering, and business analysis, we know from a 5-year experience that streamlined communication and agility result in quality work and satisfied customers. 

If you need a reliable partner for a bold digital project, just drop us a line!

‍