What is Extreme Programming?

After years of grueling iterations in traditional software development shops, burnout, over design and massive integration efforts led to its birth.

Extreme Programming XP is an Agile framework with the goal of producing higher quality software and life of the development team.

To accomplish this goal, XP defines 12 practices which are designated to 4 distinct areas. These 12 practices origin can be traced from the best practices of software development. Some of the 12 practices are taken from traditional development and others from Agile development, such as small incremental feature development over big changes, feedback loops, frequent testing and the whole team approach and applies these practices to the extreme, hence the name.

Having clearly defined 12 practices make XP the most specific of all Agile frameworks. Many other frameworks can trace their own origin from these practices, frameworks such as Test Drive Development (TDD) and Behavior Driven Development (BDD) for example.

XP’s 12 practices

Area : Fine Scale Feedback

Paired Programming

Taken from the most extreme ideas of continuous feedback, paired programming creates an immediate feedback loop for development. In paired programming, a tester and programmer or two programmers work alongside each other sharing in the development of features.

In this practice, bugs can be caught before they are even written into the code. The pair can discuss who to approach a problem and implement solutions that reach the project goals and expectations of the customer in the most efficient manner. Of course, this practice may be difficult to implement with lone wolf types, who prefer to hole up in a cube and write code. XP is more of a social framework in this regard.

Planning Game

This practice is based upon the simple idea that the customer knows the details and the development team knows the costs. The planning game is all about sharing information. At this stage, the customer will create stories, the development team will then provide estimates, the customer will prioritize to create the project plan. These steps will be repeated until the entire project is formed. Scrum takes its planning approach from this XP practice.

Test Driven Development (TDD)

TDD is also arguably the most important practice of XP. Today, TDD has become its own framework today. In TDD, the requirements are converted into very small test cases, and code is written around these tests with the idea that each problem’s solution were extremely simple. This approach encourages simple designs and inspires confidence with the whole team. The full cycle of TDD is also described further in the article.

Whole Team

While all software development has a team, XP makes the whole team work in a obviously and undeniably collective manner towards the common goal. Developers will not be silo’d away in cubes in XP development. Developers, project managers, and the testers (the three main roles in Agile) would be collaborating openly, regularly on feature development.

In this approach, each person shares information and perspective on all parts of development. The whole team approach of XP builds the common vision that is often lost in a software development team. The whole team practice applies the planning game to the internal work group.

Area : Continuous process

Continuous Integration

Integrate code at least once a day. The purpose of the “Integrate Often” mantra is to ensure that issues in the code are detected quickly, that the team receives regular feedback on development and that each developer is working with the latest code.

If you have ever worked on a large project using the waterfall methodology you have likely experienced integration problems on the massive scale I am referring to.

Integration in using waterfall can take weeks, an entire team or more may be needed to focus on the integration to resolve massive issues. By the time the product ships, it may have missed its deadline and even if it didn’t the team is worn out, stressed out and overworked from the final run. Continuous integration is XP’s solution to that problem.

Design Improvement

In a single word, this would be called “Refactoring”. If you haven’t been refactoring your code already then you’ve been doing it all wrong. Refactoring is not unique to the XP framework. For instance the Test Driven Development framework (TDD), a spin off from XP, places a heavy focus on refactoring. In TDD, the development team also works in short cycles: first writing unit tests, observing the tests fail, then writing code for the unit tests to achieve the desired output, then observing the tests pass, they move to the final stage to refactor code written in previous steps.

In XP, the goal of refactoring is the same as in TDD. That goal is to produce efficient and maintainable code. XP and TDD recognize that in the rush to build in features coding standards may not be exactly the level desired and only through refactoring of working code can those levels be achieved.

Small Releases

Small releases and Continuous Integration go hand in hand. Just as the development team needs frequent code updates and check-ins to know that issues are being resolved immediately, the customer, who also serves a a member of the team in Agile development, needs to be provided quick feedback. Allowing small releases to the client will provide valuable feedback on the system under development and the products benchmarks against the customer’s expectations for a final product.

Area : Shared Understanding

Coding Standards

As no one developer will provide the single best approach to coding for efficiency and maintainability, agreeable coding standards among a software team is desired. In developing coding standards it is vitally important to disagree constructively, should you have a member unable to take criticism or who drives all debate their way may need attention from project management. Team cohesion, trust and mutual respect are important as well.

This is an area where each member of the team should feel heard, and the outcome of discussions should be positively collective. Each member of the team is a professional and their judgement should be respected by each other member.

Collective Code Ownership

In XP, bugs are not necessarily assigned to the most senior developer. Every line of code, every bug, every piece feature waiting to be refactored belongs to the team.

In this practice, XP provides team trust and further solidifies coding standards as a developer cannot hole themselves silently in a cube writing against the collectively agreed standards. This isn’t the larger concern most express with Code Ownership.

The larger concern of Code Ownership is that bugs will be introduced by having too many hands on the wheel. The solution to this is tests, lots of tests. Unit testing and integration testing will save the project from many pitfalls and dangers, appreciate test. Test often and test early.

Simple Design

I find this practice to be relatively hard for developers with ego. The same developers who express difficulty accepting criticism will also want to design their code in their own custom flair. This type of “gold plating” should be avoided. Gold plating is the term for over designing the architecture. Design decisions come at a cost, each decision in design should be able to be justified and the value of the justification observed by members of the team.

At the other end from gold plating, is the laissez faire approach of “the design will emerge”. No, no it will not emerge and the architecture of your software should not be left to fate.

A team who adopts XP, should aim to designed software that reduces the need for refactoring while always remembering YAGNI, or “You aren’t going to need it.” In making decisions, as much information as possible should be gathered, the decision should be made as late as possible /after collecting that information.

System Metaphor

The idea of the System Metaphor is that each unit of code gets a specific name. This name should be simple and descriptive enough about the chunk of code that stakeholders and developer can converse about its progress or design in the same language. As some team members may not be technical, technical jargon should be avoided.

Having system metaphors gives meaning to the stories, they transform from an idea to having a personality of their own for the team to meet on. This practice is tied directly into a code XP value of communication. Having a team that can communicate reduces errors, improves development efficiency, team cohesion and in the end makes a better product.

Area : Programmer Welfare

Sustainable Pace

Having myself worked in both Waterfall and Agile shops, I can say the differences here among the two are amazingly wide. As I mentioned before in the area for continuous integration, in the final code push of a waterfall project the pace can be exceptional hard on the team.

When a team implements the Agile framework then these last minute massive code integrations are not a blip on the radar. There is no hard and fast rule for developing the right pace. You will have to find the groove of your team through small trial and error runs. Once you understand the pace, then planning should be with this right size velocity in mind.

Developer burnout is a real thing, and before Agile came along it was some what common. This burnout was one of the frustrations that led to its development. To avoid burnout, project velocity should be monitored, planning meetings shouldn’t push to overly burden the development team with stories. Overtime should be avoided.

If you want to demoralize the team, ask them to work overtime. Yes they will do it for a while, but they will become bitter and tired from it. When you stop working to live and start living to work, then your doing life wrong.