Extreme Programming: Values, Principles, and Practices

With software engineering such a fast-paced environment, traditional project management approaches are no longer viable. That means that IT professionals must find new ways to handle frequently changing development tasks.

Sharing this idea and focusing on the existing incremental development techniques, 17 software specialists introduced the Agile project management philosophy in 2001. Principles of flexible, fast, and collaboration-centered software development were outlined in the Agile Manifesto.

Extreme Programming (XP) is one of the numerous Agile frameworks applied by IT companies. But its key feature — emphasis on technical aspects of software development — distinguishes XP from the other approaches.

Software engineer Ken Beck introduced XP in the 90s with the goal of finding ways to writing high-qualitative software quickly and being able to adapt to customers’ changing requirements. In 1999, he refined XP approaches in the book Extreme Programming Explained: Embrace Change.

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 discuss XP’s values and principles first.

Values and principles of Extreme Programming

XP has simple rules that are based on 5 values.

• 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 efforts. • Feedback: Team members deliver software frequently, get feedback about it, and improve a product according to the new requirements. • Respect: Every person assigned to a project contributes to a common goal. • Courage: Programmers objectively evaluate their own results without making excuses and are always ready to respond to changes.

These values represent a specific mindset of motivated team players who do their best on the way to achieving a common goal. XP principles derive from these values and reflect them in more concrete ways.

Most researchers denote 5 XP principles as:

• Rapid feedback: Team members understand the given feedback and react to it right away. • Assumed simplicity: Developers need to focus on the job that is important at the moment and follow YAGNI (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles. • Incremental changes: Small changes made to a product step by step work better than big ones made at once. • Embracing change: If a client thinks a product needs to be changed, programmers should support this decision and plan how to implement new requirements. • Quality work: A team that works well, makes a valuable product and feels proud of it.

Now it’s time to learn about practices that turn a software development group into dream teams.

Extreme Programming Practices

XP suggests using 12 practices while developing software. As XP is defined by values and principles, its practices also represent them and can be clustered into four groups.

Feedback

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 (TTD) 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 able to accomplish the needed function. That’s the way TDD allows programmers to use immediate feedback to produce reliable software. You can learn more about improving software testing in our dedicated article.

The Planning Game. This is a meeting that occurs at the beginning of an iteration cycle. The development team and the customer get together to discuss and approve a product’s features. At the end of the planning game, developers plan for the upcoming iteration and release, assigning tasks for each of them.

On-site Customer. According to XP, the end customer should fully participate in development. The customer should be present all the time to answer team questions, set priorities, and resolve disputes, if necessary.

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, faster knowledge sharing but takes 15 to 60 percent more time. In this regard, it’s more reasonable trying pair programming for long-term projects.

Continual Process

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 re-used 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 early, before deployment.

Small Releases. This practice suggests releasing the first version quickly and further developing the product by making small and incremental updates. Small releases allow developers to frequently receive feedback, detect bugs early, and monitor how the product works in production. One of the methods of doing so is the continuous integration practice (CI) we mentioned before.

Code understanding

Simple Design. The best design for software is the simplest one that works. If any complexity is found, it should be removed. The right design should pass all tests, have no duplicate code, and contain the fewest possible methods and classes. It should also clearly reflect the programmer’s intent.

XP practitioners highlight that chances to simplify design are higher after the product has been in production for some time. Don Wells advises writing code for those features you plan to implement right away rather than writing it in advance for other future features: “The best approach is to create code only for the features you are implementing while you search for enough knowledge to reveal the simplest design. Then refactor incrementally to implement your new understanding and design.”

Coding Standards. A team must have common sets of coding practices, using the same formats and styles for code writing. Application of standards allows all team members to read, share, and refactor code with ease, track who worked on certain pieces of code, as well as make the learning faster for other programmers. Code written according to the same rules encourages collective ownership.

Collective Code Ownership. This practice declares a whole team’s responsibility for the design of a system. Each team member can review and update code. Developers that have access to code won’t get into a situation in which they don’t know the right place to add a new feature. The practice helps avoid code duplication. The implementation of collective code ownership encourages the team to cooperate more and feel free to bring new ideas.

System Metaphor. System metaphor stands for a simple design that has a set of certain qualities. First, a design and its structure must be understandable to new people. They should be able to start working on it without spending too much time examining specifications. Second, the naming of classes and methods should be coherent. Developers should aim at naming an object as if it already existed, which makes the overall system design understandable.

Programmer’s work conditions

40-Hour Week. XP projects require developers to work fast, be efficient, and sustain the product’s quality. To adhere to these requirements, they should feel well and rested. Keeping the work-life balance prevents professionals from burnout. In XP, the optimal number of work hours must not exceed 45 hours a week. One overtime a week is possible only if there will be none the week after.

When to use XP

It’s important to make sure a company’s size, structure, and expertise, as well as the staff’s knowledge base allow for applying XP practices. These are the factors to consider.

Highly-adaptive development. XP was designed to help development teams adapt to fast-changing requirements.

Risky projects. Teams applying XP practices are more likely to avoid problems connected with working on a new system, especially when a product owner sets strict deadlines for a project.

Small teams. XP practices are efficient for teams that don’t exceed 12 people.

Automated testing. Another factor that can influence the choice of XP is the developers’ ability to create and run unit tests.

Available customer participation. As XP requires customers, developers and managers work side-by-side, make sure your client can spend time in the office until a project ends.

Conclusion

Extreme Programming is a software development approach based on values of simplicity, communication, feedback, and courage.

Companies that build their workflow on XP principles and values create a competitive yet motivational atmosphere within and between teams. Programmers appreciate each other’s project input, deliver software quickly because they can distinguish relevant tasks from unnecessary ones. They react quickly to feedback realizing it’s a reasonable criticism aimed at making a product better.

XP teams don’t consider each technical challenge as a problem but think of it as a way to develop skills.

Liked the story? Clap us so more people can find it! 👏Originally published at AltexSoft’s blog: “Extreme Programming: Values, Principles, and Practices”