DEV Community

Cover image for Going Extreme With Extreme Programming
Omar Reda
Omar Reda

Posted on • Updated on

Going Extreme With Extreme Programming

In this article, we are going to discuss one of the software development agile methodologies which is Extreme Programming (XP).

For those who don't know enough information about agile, you can check this quick introduction before proceeding with the article.

What is Agile? 🤔

The word ‘agile’ means

  • Able to move your body quickly and easily.
  • Able to think quickly and clearly.

In business, ‘agile’ is used for describing ways of planning and doing work wherein it is understood that making changes as needed is an important part of the job. Business ‘agility’ means that a company is always in a position to take account of the market changes.

In software development, the term ‘agile’ is adapted to mean ‘the ability to respond to changes from Requirements, Technology and People.’


Origins Of Extreme Programming 🗺

Extreme Programming (XP) was first used on the Chrysler Comprehensive Compensation Program (C3), which was initiated in the mid-'90s and switched to an XP project when Kent Beck was brought on to the project to improve the performance of the system.

In October 1999, Kent Beck published Extreme Programming Explained, detailing the entire method for others, and shortly thereafter the official website was launched as well.

What Is Extreme Programming ? 🧐

XP is a set of engineering practices. Developers have to go beyond their capabilities while performing these practices. That’s where the “extreme” in the framework’s title comes from. To get a better understanding of these practices, we’ll start with describing XP’s lifecycle and the roles engaged in the process.

Similar to other Agile Methods of development, Extreme Programming aims to provide iterative and frequent small releases throughout the project, allowing both team members and customers to examine and review the project’s progress throughout the entire Software Development Life Cycle (SDLC).

When We Could Apply XP ? 😯

The general characteristics where XP is appropriate were described by Don Wells.

  • Dynamically changing software requirements.
  • Risks caused by fixed time projects using new technology.
  • Small, co-located extended development team
  • The technology you are using allows for automated unit and functional tests.

Values & Practices ⭐️🚀

Values 🤝

The five values of XP are communication, simplicity, feedback, courage, and respect and are described in more detail below.

Alt Text

  • Communication Everyone on a team works jointly at every stage of the project.
  • Simplicity Developers strive to write simple code bringing more value to a product, as it saves time and effort.
  • Feedback Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements.
  • Courage Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes.
  • Respect Every person assigned to a project contributes to a common goal.

Practices 🏋️‍♂️

The core of XP is the interconnected set of software development practices listed below. While it is possible to do these practices in isolation, many teams have found some practices reinforce the others and should be done in conjunction to fully eliminate the risks you often face in software development.

The XP Practices have changed a bit since they were initially introduced. The original twelve practices are listed below.

  1. The Planning Game
  2. Small Releases
  3. Metaphor
  4. Simple Design
  5. Test-Drived Development
  6. Refactoring
  7. Pair Programming
  8. Collective Ownership
  9. Continuous Integration
  10. 40-hour week
  11. On-site Customer
  12. Coding Standard

I'm going to discuss some of these practices that are important to be understood.

Pair Programming 👨‍💻👩‍💻

This practice requires two programmers to work jointly on the same code. While the first developer focuses on writing, the other one reviews code, suggests improvements and fixes mistakes along the way. Such teamwork results in high-quality software and faster knowledge sharing but takes about 15 percent more time. In this regard, it’s more reasonable trying pair programming for long-term projects.

Test-Driven Development 🔍

Is it possible to write a clear code quickly? The answer is yes, according to XP practitioners. The quality of software derives from short development cycles that, in turn, allow for receiving frequent feedback. And valuable feedback comes from good testing. XP teams practice test-driven development technique (TDD) that entails writing an automated unit test before the code itself. According to this approach, every piece of code must pass the test to be released. So, software engineers thereby focus on writing code that can accomplish the needed function.

Code Refactoring 🛠

To deliver business value with well-designed software in every short iteration, XP teams also use refactoring. The goal of this technique is to continuously improve code. Refactoring is about removing redundancy, eliminating unnecessary functions, increasing code coherency, and at the same time decoupling elements. Keep your code clean and simple, so you can easily understand and modify it when required would be the advice of any XP team member.

Continuous Integration 🖇

Developers always keep the system fully integrated. XP teams take iterative development to another level because they commit code multiple times a day, which is also called continuous delivery. XP practitioners understand the importance of communication. Programmers discuss which parts of the code can be reused or shared. This way, they know exactly what functionality they need to develop. The policy of shared code helps eliminate integration problems. In addition, automated testing allows developers to detect and fix errors before deployment.

Extreme Programming Rules ♻️

Don Wells published the first XP rules in 1999 to counter claims that extreme programming doesn’t support activities that are necessary to software development, such as planning, managing, and designing. From planning to testing the software, follow these basic steps for each iteration.

Alt Text

Planning 📉

The first stage is when the customer meets the development team and presents the requirements in the form of user stories to describe the desired result. The team then estimates the stories and creates a release plan broken down into iterations needed to cover the required functionality part after part. If one or more of the stories can’t be estimated, so-called spikes can be introduced which means that further research is needed.

Managing 👨‍🏫

At this stage, the project manager will set the team up to succeed in this methodology. Everyone needs to work collaboratively and effectively communicate to avoid any slipups. This stage involves:

  • Creating an open workspace for your team.
  • Setting a sustainable pace (i.e. determining the right length for iterations).
  • Scheduling a daily standup meeting.
  • Measuring project velocity (the amount of work getting done on your project).
  • Reassigning work to avoid bottlenecks or knowledge loss.
  • Changing the rules if XP isn’t working perfectly for the team.

Designing 👨‍🎨

is actually a part of the planning process, but can be set apart to emphasize its importance. It’s related to one of the main XP values that we’ll discuss below — simplicity. A good design brings logic and structure to the system and allows to avoid unnecessary complexities and redundancies.

Coding 👨‍💻👩‍💻

Is the phase during which the actual code is created by implementing specific XP practices such as coding standards, pair programming, continuous integration, and collective code ownership (the entire list is described below).

Testing 💣

Is the core of extreme programming. It is the regular activity that involves both unit tests (automated testing to determine if the developed feature works properly) and acceptance tests (customer testing to verify that the overall system is created according to the initial requirements).

🧔👱‍♀️ Roles In XP 👨‍🦱👩‍🦰

  1. Customers are expected to be heavily engaged in the development process by creating user stories, providing continuous feedback, and making all the necessary business decisions related to the project.
  2. Programmers or developers are the team members that actually create the product. They are responsible for implementing user stories and conducting user tests (sometimes a separate Tester role is set apart). Since XP is usually associated with cross-functional teams, the skill set of such members can be different.
  3. Trackers or managers link customers and developers. It’s not a required role and can be performed by one of the developers. These people organize the meetups, regulate discussions, and keep track of important progress KPIs.
  4. Coaches can be included in the teams as mentors to help with understanding the XP practices. It’s usually an outside assistant or external consultant who is not involved in the development process, but has used XP before and so can help avoid mistakes.

Agility principles are becoming increasingly popular as they prove their effectiveness. Even though extreme programming is not the most widespread methodology, it offers a lot of sensible practices that can benefit software development and are worth considering for implementation in your projects.


That's it, I hope this article was beneficial to you and you enjoyed reading it. Furthermore, feel free to contact me on email from here Gamil if you want to ask about anything, and you can find me on LinkedIn, My Website.

Top comments (0)