Extreme programming; tips & advantages

We constantly publish articles about Agile methodology, Scrum, Kanban, TDD, CI, Unit testing, etc. But we haven’t spoken that much about Extreme programming. Therefore this time I decided to write about XP as another Agile methodology.

What is extreme programming

Extreme Programming (XP) is an agile software development methodology that is intended to improve software quality and responsiveness to changing customer requirements. It emphasizes business results first and takes an incremental, “get something started” approach to build the product, using continual testing and revision. It advocates frequent releases in short development cycles, which are intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. It really simplifies and speeds up the process of developing new software, making it possible to launch a new product as fast as possible with a solid MVP. Extreme Programming is really about bringing efficiency in the coding process and providing customers with maximum value.

As we said, Extreme Programming is one of the Agile methodologies. It shares all Agile principles including strong customer involvement in the software development process, good communication inside of the teams, and iterative cycles of development.

Extreme Programming is about putting individuals and interactions over processes and tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan. It is based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

In Extreme Programming, instead of delivering everything you could possibly want on some date far in the future, this process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements.

Extreme programming was the first Agile method to truly challenge traditional Waterfall methods. It changed traditional requirements-gathering techniques, brought testing to the forefront of the delivery process, and helped popularize core software engineering practices like automated testing, refactoring, continuous integration (CI), and test-driven development (TDD).

History & fundamental idea of extreme programming

XP was conceived and developed by Kent Beck, who wrote “Extreme Programming Explained”, the book based on his concept. The book addresses the issues faced by small development teams working in an environment of ever-changing requirements. Beck emphasizes that in order to write the code, you have to write a test for it first so that you will know when your code succeeds. Beck also introduces the relatively novel idea that code should be written by pairs of programmers, forcing the main programmer to describe the code to the other programmer and perhaps to stimulate further ideas. Normally XP is for teams between 2 and 12, though larger projects of 30 have reported success as well.

Beck’s fundamental idea is to start simply, build something real that works in its limited way, and then fit it into a design structure that is built for further code building. The XP team includes not only the developers but the managers and customers as well, all working together elbow to elbow.

Values that drive the XP life cycle are continual communication with the customer and amongst the team, simplicity, focusing on the minimalist solution, frequent feedback through unit and acceptance testing, and the courage to take on problems proactively and integrate testing and changes in the development phase.

How does extreme programming work?

Normally all iterations in extreme programming consist of five basic phases in its life cycle: planning, designing, coding, testing, and listening. Each of these phases includes a number of rules and practices. And now we will look at them more in detail:

1. Extreme Planning 

The first phase of the Extreme Programming life cycle is planning, where customers meet with the development team to create user stories or requirements. The development team converts user stories into iterations that cover a small part of the functionality or features required. The programming team prepares the plan, time, and costs of carrying out the iterations, and individual developers sign up for iterations.

• On-site Customers

On-site customer means to include real-life customers in the development process. The customers will be always available to answer questions, provide the requirements, and set the priorities. As a result, this will ensure the customers’ satisfaction by including them and will avoid frustration caused by negative feedback caused by misunderstanding the requirements.

• The Planning Game

XP planning addresses two key questions in software development: predicting what will be accomplished by the due date, and determining what to do next. There are two key planning steps in XP, address these two questions:

1) Release planning is a practice where the customer presents the desired features to the programmers, and the programmers estimate their difficulty and cost.

2) Iteration Planning is the practice where the team is given direction every couple of weeks. XP teams build software in two-week iterations, delivering running helpful software at the end of each iteration. During iteration planning, the customer presents the features desired for the next two weeks.

• Small Releases

The development team is required to make small frequent releases of working software that customers can evaluate. The first release includes the smallest set of useful features set. Subsequent releases include newly added features. Small releases are important for both the customers and the development team, they provide necessary feedback to continue on the right direction. Here it is important to release early and often, adding a few features each time.

2. Extreme Designing 

Using systems metaphor or standards on names, class names and methods, and agreeing on uniform styles and formats to ensure compatibility among the work of different team members.

• Simple Design

In the designing phase, XP concentrates on keeping things as simple as possible and as long as possible. No extra functionality is added early with the assumption that it might be used later on.

• System Metaphor

System metaphor is a common vision of the project in hand. The metaphor keeps the development team organized by providing a naming convention. A naming convention is very important as it helps understand the overall design of the system and reuse code. It saves time as it makes it easier to find the functionality you are looking for and to know where to put certain functionality.

• Refactoring

Refactoring is a process of continuous design improvement to keep the design as simple as possible and to avoid needless clutter and complexity. Refactoring tends to remove redundancy and duplications and increase code cohesion while decreasing its dependencies. Refactoring throughout the entire project saves time, increases quality, and improves understandability. It should be supported by comprehensive testing to ensure that nothing is broken.

3. Extreme Coding

In the coding phase, XP concentrates on having coding standards to keep the code consistent and easy to read. The coding phase begins by creating test first units. Pair programming is the business card of XP methodology. Each pair of programmers writes their code and then integrates it together. The development team has collective code ownership. Each team member can change or refactor any part of the code.

• Coding Standards

Coding standards keeps the code consistent and easy to read and refactor, which is very important in XP as it makes the code look as if one developer has written it. Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it who on the team has touched a specific piece of code.

• Pair Programming

Pair programming is one of the practices that distinguish the XP methodology. Each pair of programmers works together to develop certain functionality. This increases software quality. In addition to better code quality, it helps with communicating knowledge and no one developer becomes a bottleneck.

• 40-Hour Work Week

A 40-hour work week means that the developers should not work more than 40 hours per week, no overtime. This gives the developers a comfortable working environment with no pressure. In pressure times, up to one week of overtime is acceptable. Multiple weeks of overtime exhaust the developers and reduce their productivity.

• Continuous Integration

XP team should maintain a fully integrated project. The integration process should be continued and carefully controlled. Developers should integrate tested code at least daily. CI often avoids diverging or fragmented development efforts, where developers are not communicating with each other about what can be reused, or what could be shared. Continuous integration ensures that everyone has the latest version of the project. It also avoids or detects compatibility problems early.

• Collective Code Ownership

The development team has collective code ownership. Each team member can change or refactor any part of the code. It ensures that no one developer becomes a bottleneck for changes and it allows programmers to reuse any functionality that might be required by multiple user stories.

4. Extreme Testing

Extreme Programming is obsessed with feedback, and in software development, good feedback requires good testing. Top XP teams practice “test-driven development”.
Test in XP comes in two types: unit tests and customer tests. The coding phase begins by creating test first units for each feature to be developed. The developed feature should pass all the test units to be considered as completed. This is called unit testing. Unit Tests are automated tests written by the developers to test functionality as they write it. Acceptance Tests or customer tests are specified by the customer to test that the overall system is functioning as planned. Automated testing results in much better overall quality. Basically, before programmers add a feature, they write a test for it.

• Unit Testing

As we discussed, unit tests are automated tests written by the developers during the coding phase to test features as they are developed. Unit tests are very important as it can save a large amount of effort.

• Acceptance Testing

Acceptance tests are tests done by the customers to ensure that the overall system contains all the required features. The acceptance tests should be done at each of the process iterations to ensure that the new release contains all the agreed-upon features.

5. Extreme Listening

The basis of extreme programming is a continuous mechanism of customer involvement through feedback during the development phase. Programmers must listen to what the customers and project managers need the system to do, and what business value they want to provide. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved.

Roles in extreme programming

• Tracker: goes around and asks each Programmer how he’s doing, listens to the answer, and takes action if things seem to be going off track. Actions include suggesting a CRC session, setting up a meeting with a customer, and asking a coach or another programmer to help.
• Customer: writes user stories and specifies functional tests. Sets priorities, explains stories, views CRC sessions.
• Programmer: estimates stories, define engineering tasks from stories, estimates how long stories and tasks will take, and implements stories and unit tests.
• Tester: implements and runs functional tests. Graph results make sure people know when test results decline.
• Coach: Schedules meetings, makes sure the meeting process is followed, records results of meeting for future reporting, passes to tracker.

Some roles can be combined in the same individual. For example, the same person could have the Coach and Tracker role. Some roles probably should not be combined for example Programmer-Tracker and coach probably shouldn’t combine with anything except Tracker.

Advantages of extreme programming

• The greatest advantage of Extreme Programming is that this methodology allows software development companies to save costs and time required for project realization. XP eliminates unproductive activities to reduce the costs and frustration of everyone involved. It allows developers to focus on coding.

• One of the major advantages of Extreme Programming is that it reduces the risks related to programming or related to project failure. In the end, XP ensures that the client gets exactly what he wants.

• Simplicity is one more advantage of Extreme Programming projects. The developers who prefer to use this methodology create extremely simple code that can be improved at any moment.

• The basic advantage of XP is that the whole process is visible and accountable. The developers make concrete commitments about what they will accomplish, and show concrete progress.

• Constant feedback; demonstrate the software early and often, listen carefully, and make any changes needed. Sprints help the team to move in the right direction.

• This approach creates working software faster. Regular testing at the development stage ensures the detection of all bugs, and the use of customer-approved validation tests to determine the successful completion of a coding block ensures the implementation of only what the customer wants and nothing more.

• Extreme Programming helps increase employee satisfaction and retention. Extreme Programming is a value-driven approach that sets fixed work time, with little scope for overtime. The breakdown of the project scope into subcomponents and the constant customer feedback prevent the accumulation of much work to be completed before a tight deadline.

• Teamwork; everyone is part of the team. Team members work together on everything from requirements to code. Developers work in pairs; pair programming and never feel alone or forgotten.

I hope you liked the article and you found it useful. If you are interested in agile project management and best practices in software development, I highly recommend you to subscribe to our monthly newsletter. 

Also, if you’re looking for software development companies that could help you with one of your projects, here’s a list of great software development companies in Europe, give it a look! 

If you found this article interesting, you might like…

• Top agile blocks to track
• 5 benefits of agile project management
• Benefits of continuous integration
• 20 advantages of test-driven development
• Top business blogs to read
• Benefits & examples of microservices architecture implementation
• Top 10 benefits you will get by using docker
• Benefits of software architecture
• Top software development blogs
• DevOps technologies & benefits
• Top 8 benefits of unit testing