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­men­ted. What’s makes this approach to de­vel­op­ment so extreme?

Extreme pro­gram­ming (XP) is con­sidered the most radical form of agile software de­vel­op­ment, which is why it’s called “extreme.” There is probably no other meth­od­o­logy as agile as XP, least of all tra­di­tion­al pro­gram­ming practices. Extreme pro­gram­ming is dis­tinctly different from other ap­proaches such as the waterfall model which has a variety of problems according to the inventors of XP. In the mid-1990s, software de­velopers Kent Beck, Ward Cun­ning­ham and Ron Jeffries decided to re­volu­tion­ise 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­ity in de­velopers 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­tinu­ously tested, discussed and released in short cycles. This way, mistakes can be detected and elim­in­ated quickly.

XP has a very clear framework for meeting re­quire­ments. It is based on a variety of values, prin­ciples 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­or­ate as ef­fect­ively as possible and create an excellent product.

Com­mu­nic­a­tion is important in XP, both between team members and between de­velopers and customers. By con­tinu­ously sharing in­form­a­tion, teams can address problems im­me­di­ately. Everyone involved must be in com­mu­nic­a­tion with each other at all times in order to detect errors early on. Com­mu­nic­a­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­vant­ages: By focusing solely on essential factors, pro­gram­mers don’t dwell on un­im­port­ant 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­ten­ance. Fur­ther­more, the simplest possible code is easier to un­der­stand, and that supports com­mu­nic­a­tion: If the whole team un­der­stands the source code, it’s easier for them to com­mu­nic­ate about it.

This value is closely linked to the emphasis on direct com­mu­nic­a­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­tinu­ously 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­spons­ible for them. A team that works according to XP values does not make excuses. Nobody on the team should try to minimise 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­gan­isa­tion­al struc­tures, to question your own methods, to accept criticism and com­pletely 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­ately. Finally, managers should also show respect for the de­vel­op­ment team and ensure that employees have the necessary skills and resources.

Prin­ciples are between values and practices in extreme pro­gram­ming. They link the abstract with the concrete. Prin­ciples 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­pli­city basically cor­res­ponds to the value of sim­pli­city, 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­ne­ces­sary work, pro­gram­mers shouldn’t add func­tion­al­ity unless it’s spe­cific­ally requested.
• Don’t repeat yourself (DRY): You should avoid re­dund­ancy 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­ment­ally. 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­ment­al 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­it­ate 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­ciples presented here are also used in other agile meth­od­o­lo­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­velopers write a test en­vir­on­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­res­ent­at­ive 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­it­ies.

Finally, pair pro­gram­ming ensures ensures that two de­velopers 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­mately better and requires fewer rewrites.

XP teams con­tinu­ously revise their code. The purpose of this re­fact­or­ing is to improve the source code as well as remove re­pe­ti­tions and un­ne­ces­sary parts of the code. This optimised 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­tinu­ous in­teg­ra­tion and other agile methods to con­tinu­ously integrate new code into the overall project. De­velopers merge their work with the overall project several times a day. This ensures that the work of in­di­vidu­al team members is con­tinu­ously 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­in­ated with the next update. The customer con­stantly has the op­por­tun­ity 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­ne­ces­sar­ily complex must be removed. Extreme pro­gram­ming en­cour­ages de­velopers to avoid du­plic­a­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 strengthens col­lect­ive code ownership: De­velopers view the code as a col­lect­ive product instead of assigning in­di­vidu­al re­spons­ib­il­ity for certain parts of the code and the errors it contains. This way, the entire team bears re­spons­ib­il­ity for errors as well as successes. This technique also en­cour­ages pro­gram­mers to work on other de­velopers’ code and con­trib­ute 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­plan­at­ory 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­velopers and customers.

Extreme pro­gram­ming is heavily focused on the customer. In fact, the customer is con­sidered part of the team and always has at least one rep­res­ent­at­ive on site (on-site customer). The customer defines the product re­quire­ments but does not dictate how the ob­ject­ives are to be achieved. The customer is merely re­spons­ible for pri­or­it­ising in­di­vidu­al 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­res­ent­at­ives 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­divided 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­velopers are re­spons­ible for de­vel­op­ing the product as well as re­spond­ing to the needs of customers by es­tim­at­ing time and effort, creating a schedule and planning im­ple­ment­a­tion.

De­velopers 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­velopers prescribe a 40-hour week. The project suffers if de­velopers are over­worked. As a result, the de­vel­op­ment team sets its own schedule.

The manager is the link between de­velopers and customers. People in this role bring customers and de­velopers together and moderate meetings like the Planning Game. In doing so, the manager ensures that everyone adheres to pre­vi­ously defined rules and general con­ven­tions for con­struct­ive 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­sist­ently apply this meth­od­o­logy. 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­in­ary 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­tainty arises.

External con­sult­ants 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­velopers can implement projects as they see fit, instead of con­stantly making com­prom­ises. 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­velopers 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­tinu­ous testing results in stable software systems. The iterative approach, combined with a min­im­al­ist mindset, ensures that teams develop only those features that are truly needed for the project.