Extreme Pro­gram­ming: Software de­vel­op­ment to the extreme

These days, there are many different offshoots of agile software de­vel­op­ment. In addition to scrum and kanban, extreme pro­gram­ming is another method that’s always being discussed and im­ple­ment­ed. What’s makes this approach to de­vel­op­ment so extreme?

Extreme pro­gram­ming (XP) is con­sid­ered the most radical form of agile software de­vel­op­ment, which is why it’s called “extreme.” There is probably no other method­ol­o­gy as agile as XP, least of all tra­di­tion­al pro­gram­ming practices. Extreme pro­gram­ming is dis­tinct­ly different from other ap­proach­es such as the waterfall model which has a variety of problems according to the inventors of XP. In the mid-1990s, software de­vel­op­ers Kent Beck, Ward Cun­ning­ham and Ron Jeffries decided to rev­o­lu­tion­ize tra­di­tion­al de­vel­op­ment practices and go in a new direction.

Extreme pro­gram­ming is geared to the customer’s re­quire­ments. This might sound like a given at first, but tra­di­tion­al software de­vel­op­ment doesn’t always cater to customer needs. Things get even more difficult when these re­quire­ments change on a regular basis. XP also tries to encourage cre­ativ­i­ty in de­vel­op­ers and accepts mistakes as a natural part of workflow.

Like other agile methods, XP is also based on iterative processes. XP breaks with the practice of com­plet­ing a large project from start to finish in one go and investing many months of work only to find af­ter­wards that the final product isn’t right. Instead, work is con­tin­u­ous­ly tested, discussed and released in short cycles. This way, mistakes can be detected and elim­i­nat­ed quickly.

XP has a very clear framework for meeting re­quire­ments. It is based on a variety of values, prin­ci­ples and practices. In addition, people are assigned specific roles so that tasks are clearly delegated.

XP uses five values to try to change the general attitude toward pro­gram­ming. The team as a whole should adopt a certain mindset in order to col­lab­o­rate as ef­fec­tive­ly as possible and create an excellent product.

Com­mu­ni­ca­tion is important in XP, both between team members and between de­vel­op­ers and customers. By con­tin­u­ous­ly sharing in­for­ma­tion, teams can address problems im­me­di­ate­ly. Everyone involved must be in com­mu­ni­ca­tion with each other at all times in order to detect errors early on. Com­mu­ni­ca­tion also ensures that everyone shares the same level of knowledge and feels committed to the project. Face-to-face con­ver­sa­tions are preferred over written messages.

In XP, pro­gram­mers always strive for the simplest solution. This has many ad­van­tages: By focusing solely on essential factors, pro­gram­mers don’t dwell on unim­por­tant things. This also means de­vel­op­ing only the features that are needed today instead of focusing on possible future re­quire­ments. That way, the team speeds up the de­vel­op­ment process. A lean product is also much easier to manage when it comes to en­hance­ments and main­te­nance. Fur­ther­more, the simplest possible code is easier to un­der­stand, and that supports com­mu­ni­ca­tion: If the whole team un­der­stands the source code, it’s easier for them to com­mu­ni­cate about it.

This value is closely linked to the emphasis on direct com­mu­ni­ca­tion. The customer should be able to express criticism as often as possible. Extreme pro­gram­ming also treats messages from the system (logs) as feedback. In order to create a culture of feedback that supports XP, it’s important to think in small steps: The team works in short cycles, con­tin­u­ous­ly tests the code and presents each update to the customer at frequent intervals. This way, the team can make changes and fix bugs early on.

Extreme pro­gram­ming defines courage as the will­ing­ness to tell the truth, even if it might be un­pleas­ant. Any errors in the product have to be pointed out, even if you yourself are re­spon­si­ble for them. A team that works according to XP values does not make excuses. Nobody on the team should try to minimize their in­volve­ment in a mistake because everybody is working toward a common goal. Moreover, this value means having the courage to change or­ga­ni­za­tion­al struc­tures, to question your own methods, to accept criticism and com­plete­ly rewrite code, if necessary.

Mutual respect is necessary in order for the team to work in harmony and deliver excellent work. Respect also means that one developer doesn’t sabotage the work of another by altering it. Respect extends beyond the team to the customer. You have to take other peoples’ concerns seriously in order to respond to them ap­pro­pri­ate­ly. Finally, managers should also show respect for the de­vel­op­ment team and ensure that employees have the necessary skills and resources.

Prin­ci­ples are between values and practices in extreme pro­gram­ming. They link the abstract with the concrete. Prin­ci­ples are derived more or less from the values described above.

Teams should obtain feedback as early as possible and implement changes as quickly as possible. Pro­gram­mers should take action in response to feedback from the system itself (when testing code) within seconds or minutes rather than col­lect­ing the feedback first. Teams should obtain feedback from customers and take action within days or weeks.

The principle of sim­plic­i­ty basically cor­re­sponds to the value of sim­plic­i­ty, but with more specific in­struc­tions for putting the concept into practice. Two methods are used:

• You ain’t gonna need it (YAGNI): To avoid un­nec­es­sary work, pro­gram­mers shouldn’t add func­tion­al­i­ty unless it’s specif­i­cal­ly requested.
• Don’t repeat yourself (DRY): You should avoid re­dun­dan­cy and design your code so that a change only has to be made once and not in several places.

In extreme pro­gram­ming, changes are always made in small steps. Instead of applying big updates all at once to eliminate multiple sources of error, the team addresses problems in­cre­men­tal­ly. This ensures that the team can respond faster and that the changes are easier to un­der­stand. This principle extends beyond program code: Changes in design or even in the structure of the team itself should be made in small, in­cre­men­tal steps.

Since extreme pro­gram­ming focuses heavily on the customer, the customer’s change requests have high priority. That means the entire team needs to have a positive attitude toward these changes rather than standing in their way. The team should actually encourage the customer to make change requests rather than trying to dissuade the customer.

This one might sound obvious, but it’s very important for the success of extreme pro­gram­ming: The team needs to produce high-quality work. The customer decides what high quality is. However, effective man­age­ment is required in order to fa­cil­i­tate quality work. If all the factors are right and the team is satisfied with their work, it will have a positive effect on morale.

XP practices are very specific in­struc­tions and methods. Whereas the values and prin­ci­ples presented here are also used in other agile method­olo­gies, the specific practices of extreme pro­gram­ming are the dif­fer­en­ti­at­ing features of this method. They too have changed slightly over time and vary depending on the source you consult. Practices are generally divided into four different areas.

De­vel­op­ment teams work in extremely short cycles in extreme pro­gram­ming. This way, the code they write can be tested over and over again. Test-driven de­vel­op­ment is unique because it requires that de­vel­op­ers write a test en­vi­ron­ment before the actual source code is written. Code that doesn’t pass this test cannot be developed further. At this point, the feedback comes from the system itself.

The Planning Game is a meeting that takes place at the beginning of each de­vel­op­ment phase. The team and customer meet to discuss the work completed so far, give feedback, and talk about future features. Tasks are then assigned.

The concept of an on-site customer also ensures regular feedback. Ideally, at least one rep­re­sen­ta­tive of the customer should be a permanent part of the team in order to answer questions quickly or to introduce ideas and help establish pri­or­i­ties.

Finally, pair pro­gram­ming ensures ensures that two de­vel­op­ers always work on the same code at the same time, based on the premise that two heads are better than one. While one pro­gram­mer writes the code, the other reviews the source code, gives sug­ges­tions for im­prove­ment and points out errors. Although this method is very costly because it uses two people to perform one task, the resulting code is ul­ti­mate­ly better and requires fewer rewrites.

XP teams con­tin­u­ous­ly revise their code. The purpose of this refac­tor­ing is to improve the source code as well as remove rep­e­ti­tions and un­nec­es­sary parts of the code. This optimized code is easier to un­der­stand, even for outside readers, and is less prone to errors.

In extreme pro­gram­ming, teams use con­tin­u­ous in­te­gra­tion and other agile methods to con­tin­u­ous­ly integrate new code into the overall project. De­vel­op­ers merge their work with the overall project several times a day. This ensures that the work of in­di­vid­ual team members is con­tin­u­ous­ly reviewed and everyone is working on the latest build.

Func­tion­ing programs and updates are released as early as possible, in line with the XP values. Small releases also increase the frequency of feedback. Errors can be detected faster and elim­i­nat­ed with the next update. The customer con­stant­ly has the op­por­tu­ni­ty to test the latest code and to offer criticism and sug­ges­tions.

A simple design ensures that the code is easily un­der­stood by everyone involved. Anything that makes the source code un­nec­es­sar­i­ly complex must be removed. Extreme pro­gram­ming en­cour­ages de­vel­op­ers to avoid du­pli­ca­tion. The pro­gram­mer’s goal should also be clear from the source code.

Coding standards are defined so that entire team can work hand in hand. These standards specify the style and format for source code. Pro­gram­mers should be able to find their way around each other’s code and should always be able to un­der­stand who made which changes.

The ability to work together on the code strength­ens col­lec­tive code ownership: De­vel­op­ers view the code as a col­lec­tive product instead of assigning in­di­vid­ual re­spon­si­bil­i­ty for certain parts of the code and the errors it contains. This way, the entire team bears re­spon­si­bil­i­ty for errors as well as successes. This technique also en­cour­ages pro­gram­mers to work on other de­vel­op­ers’ code and con­tribute ideas.

Extreme pro­gram­ming uses the system metaphor technique to further improve un­der­stand­ing of the source code. This practice involves de­scrib­ing the project in the simplest terms possible, including the use of metaphors. It also involves ensuring that naming con­ven­tions for objects, classes or functions in the code are as self-ex­plana­to­ry as possible. With this practice, anyone who joins the team later can quickly un­der­stand the code. Even non-pro­gram­mers can get a general idea of the source code.

The teams’ well-being is important for the project’s success: Team members have to be well-rested and motivated to deliver high-quality work. To ensure this, extreme pro­gram­ming pre­scribes a 40-hour week. Overtime must be avoided at all costs and is only allowed if the following week does not include any overtime.

Extreme pro­gram­ming uses roles to share tasks and skills with everyone involved, both de­vel­op­ers and customers.

Extreme pro­gram­ming is heavily focused on the customer. In fact, the customer is con­sid­ered part of the team and always has at least one rep­re­sen­ta­tive on site (on-site customer). The customer defines the product re­quire­ments but does not dictate how the ob­jec­tives are to be achieved. The customer is merely re­spon­si­ble for pri­or­i­tiz­ing in­di­vid­ual areas of the project. This also includes making its own wishes clear.

The role of the customer can be assumed by one person or by a team of different rep­re­sen­ta­tives of the customer. In practice, product managers or even marketing employees often perform these tasks (but always in line with the goal of the project).

The de­vel­op­ment team is not sub­di­vid­ed into different roles. In other words, anyone who actively creates the product falls under the role of developer. Depending on the re­quire­ments of the project, this role may include pro­gram­mers as well as others involved in creating the product. De­vel­op­ers are re­spon­si­ble for de­vel­op­ing the product as well as re­spond­ing to the needs of customers by es­ti­mat­ing time and effort, creating a schedule and planning im­ple­men­ta­tion.

De­vel­op­ers also have the right to request help when needed, which can mean asking man­age­ment for ad­di­tion­al resources. Fur­ther­more, XP practices for de­vel­op­ers prescribe a 40-hour week. The project suffers if de­vel­op­ers are over­worked. As a result, the de­vel­op­ment team sets its own schedule.

The manager is the link between de­vel­op­ers and customers. People in this role bring customers and de­vel­op­ers together and moderate meetings like the Planning Game. In doing so, the manager ensures that everyone adheres to pre­vi­ous­ly defined rules and general con­ven­tions for con­struc­tive dis­cus­sions. The manager also assumes the role of a mediator, if necessary.

This role is sometimes referred to as tracker. That’s because the manager’s tasks include tracking key metrics (such as the time each person spends on the project).

The entire team (including the customer) must be able to handle extreme pro­gram­ming and con­sis­tent­ly apply this method­ol­o­gy. A coach can help ensure that everyone has a shared un­der­stand­ing of processes. This person is not involved in actual product de­vel­op­ment and is merely an outside assistant similar to a scrum master. The team can review rules and practices with the coach during pre­lim­i­nary meetings. Ideally, the coach mentors the team through­out the entire de­vel­op­ment process, is available to answer questions and assists when un­cer­tain­ty arises.

External con­sul­tants are often hired as coaches. A coach may also be someone from another de­part­ment in the company. Dual roles (a developer who also fills the role of coach) should be avoided.

Extreme pro­gram­ming has given vital impetus to software de­vel­op­ment, but it’s not suitable for every scenario and team. XP assumes that the customer does not have a clear picture of the finished product at the beginning of the project. In these cases, the software can be agile, meaning it can be gradually planned and developed.

This way, the customer is satisfied: The de­vel­op­ment team works with the customer to find the right solution and the customer is involved in every step. Fur­ther­more, de­vel­op­ers can implement projects as they see fit, instead of con­stant­ly making com­pro­mis­es. However, it’s very difficult to use XP if the customer comes to the de­vel­op­ment team with a finished product de­scrip­tion and a list of features.

Pair pro­gram­ming in par­tic­u­lar can present problems for small teams because they don’t have the necessary resources for it. Plus, regular meetings with customers take up time that could be spent on actual pro­gram­ming. In an ideal situation, that doesn’t matter: The final product will clearly be better if the team has the time and resources they need.

However, in the real world, de­vel­op­ers are con­strained by limited budgets and clear deadlines. Fur­ther­more, the customer may lack the interest or ability to get involved to the extent that XP requires.

However, if the cir­cum­stances are right for extreme pro­gram­ming, a team can deliver an excellent product with this method. Con­tin­u­ous testing results in stable software systems. The iterative approach, combined with a min­i­mal­ist mindset, ensures that teams develop only those features that are truly needed for the project.