EDUCBA

Home Human Resource Human Resource Resources Entrepreneurship Development Extreme Programming

Extreme Programming

By Jesal ShethnaJesal Shethna

Programming

Image source: pixabay.com

Introduction to Extreme Programming

Imagine this: A software development project for a new product based on the first-to-market advantage has just been spotted on your company’s radar. Traditional extreme programming methods, where the client knows “exactly” what they want, are out. Your team is small and composed of young professionals who are likely to respond well to a radical project management model. What are your options?

You’re likely to say Agile Project Management, of course! But which methodology would you like to use? There are several options: for one, there’s the hugely popular Scrum: which involves creating short “sprints” based on the customer backlog of tasks. And then, there’s Kanban, which works on optimizing the pipeline of work. Extreme Programming is often abbreviated to XP, which focuses on amplifying the positive aspects of traditional programming models, so they work to their maximum potential.

Start Your Free Human Resource (HR) Course

Human resource processes, human resources management & others

It is a hugely popular (although not as popular as Scrum) methodology focused on meeting changing client requirements. The first Extreme Programming project was started in March 1996 by Kent Beck at Chrysler. In his 1999 book, Extreme Programming Explained: Embrace Change, he detailed software development aspects.

Kent Beck was also the pioneer of test-driven development, which put use-case testing on the radar to improve over the way things were done then: writing lines and lines of code and then testing it. He was also one of the Agile Manifesto’s original signatories, helping shape the manifesto to change the way extreme programming software was written.

Values of Extreme Programming

The five values of Extreme Programming based on are expalined.

Communication

It does not depend on extensive documentation. As a matter of fact, extreme programming documentation is suggested only when necessary. So the methodology relies heavily on communication between team members and also with the users.

Simplicity

This is at the core of Extreme Programming. The methodology favours simple designs, not thinking too far ahead into the future, but focusing on today’s requirements while making the program itself robust enough to add the requirements the future throws up.

Feedback

This essential loop of going back and forth differentiates Agile systems in general and Extreme Programming, particularly from other software project management methodologies. Continuous feedback can work in different ways, but they all work towards making the system stronger and more reliable.

Feedback can come in different flavours:

  • From the Program itself: Code is vigorously tested throughout the project development cycle to implement changes.
  • From the client: This is an essential part of most Agile systems. Clients write the acceptance tests that the development is based on, which forms the backbone of the development process. All iterations are also delivered to the client for periodic feedback.
  • From the team: Once a new use case/story has been created, the team immediately reverts to costing and timeline estimation, firming up requirements as they arise. In Extreme Programming, no one person “owns” any code, and therefore, within extreme programming teams, feedback on one other’s code is encouraged.

Courage

This might seem like a strange value in extreme programming for software development, more suited to something like the Army or the Marines! However, think about it: Software projects have for long been bogged down by traditional extreme programming methods of management, secure in the comfort of extensive documentation and hierarchy that doesn’t allow for innovation. This value exemplifies Extreme Programming’s core: Be ready to jump without a parachute if it comes to that! Look at this different management style, be ready to be responsible, renounce hierarchy, and be responsible and work without knowing everything at the beginning itself.

Respect

Respect, the fifth value, was added later and meant respect for others and the self. It also implies respect for the code being written and for the client’s expectations and needs. This value underlies communication between different stakeholders, as well.

Activities of an Extreme Programming Project

It distinguishes four simple activities of a project. They are:

  • Coding: It considers this the most important activity. “Without code, there is nothing,” says Kent Beck, the founder of Extreme Programming.
  • Testing: Code is just that unless tested. It is obsessive about testing, using unit tests to confirm that the code is working and client-generated acceptance tests to confirm that the code is testing what needs to be tested.
  • Listening: Listening, exemplified by the core value of communication, is an activity that requires the developers not merely to hear the clients but really listen to what they want. Developing and business are two different things, and often, developers fail to understand the business case of a particular decision. The customer’s needs and the developers’ form the basis of the “listening” activity.
  • Designing: It might surprise you that in a software development project, the designing activity, often so important and primary, is placed at the end. This is because Extreme Programming deliberately wants to get people out of the “design and develop” mindset that the industry has nurtured for many years. It is not to limit the importance of designing. Rather, good and minimal design is one of the hallmarks of a project.

From the values and activities emerge the 12 principles of Extreme Programming, as devised by its founder, in his book, Extreme Programming Explained.

  • Planning Game
  • Pair Programming
  • Test-Driven Development
  • Whole Team
  • Continuous Integration
  • Design Improvement
  • Small Releases
  • Coding Standards
  • Collective Code Ownership
  • Simple Design
  • System Metaphor
  • Sustainable Pace

A few of these extreme programming practices, all mapped to software engineering’s best practices, are different from generic Agile methodologies. Some of the practices of extreme programming are explained below:

  1. Planning Game

This is the planning part of the project, referred to as the “Planning Game”. It includes planning for the next iteration and release, in consultation with the user/client, as well as internal planning of the teams, as to the tasks they will work on.

  1. Pair Programming

This involves two people working on a piece of code. One person, called the keyboard, types in the code while the other, called the monitor, oversees the code, commenting and refining it, as the need may arise. The two people often interchange their roles. This has been proven to improve the efficiency of code significantly. This may not be suited to all development scenarios, and that is something to consider before signing up for Extreme Programming.

  1. Test-driven development

All written code is reviewed unit-wise, i.e., each piece of code that can do something is first tested. Extreme Programming places a lot of emphasis on testing. This helps confirm that the code works and so that it can then be considered for inclusion into the extreme programming project itself. It is analogous to unit tests in school: small pieces of information tested so that the teacher/student can make course corrections and does not flounder during the annual examinations!

  1. Design Improvement (Refactoring)

Based on their simplicity feature, XP projects aim to improve upon the code that is written continually. This means that the entire code (and sometimes, the database too) is always improved upon. Refactoring does not add any functionality; it merely improves the existing code. It makes it tighter and clearer. It is akin to editing a piece of writing, polishing it and making it better.

  1. Simple design

In Extreme Programming, features are not added until specifically required. Even if the code being worked on currently is very similar to what might be required in the future, it is not taken up unless it is agreed upon as a user story.

  1. System Metaphor

This includes the standardization of all naming conventions so that their purpose and function is easily deciphered. For instance the <NewUser> or <ReplaceDefaultAddress> operations can help any programmer understand their functionality. This should be made across the entire extreme programming project to make it easy for anyone to look at the code and modify or better it, as the case may be.

extreme programming

Roles within an Extreme Programming Project

Like Scrum, it has a few designated roles within each project. Now, the roles need not always be performed by distinct people, and a person can take on more than one role.

The Extreme Programming roles are:

  • Customer: Self-explanatory. The reason for the project. She decides what the project needs to do. She provides the user stories.
  • Programmer: This is the person who:
    • Takes the stories that the customer comes up with
    • Creates programming tasks out of stories
    • Implements the user stories
    • Tests the code by unit
  • Coach: The coach generally ensures that the project is on track and jumps in to help.
  • Tracker: The Tracker makes specific enquiries to programmers at a set interval. Typically, he goes around checking the progress of programmers, offering help where needed in several ways: rolling up sleeves and helping directly with the code, letting the Coach know, or setting up a meeting with the customer, as the need may be.
  • Tester: Runs functional tests. The tester does not run unit tests, which the programmers themselves run.
  • Doomsayer: This, as the name suggests, is akin to the Black Hat in Edward De Bono’s system of group thinking. Anyone could be a Doomsayer, who typically flags potential problems and helps keep trouble in the correct perspective.
  • Manager: The Manager in an Extreme Programming project is more like a scheduler, ensuring that the meetings occur as planned and ensuring the decisions taken during meetings are passed on to the appropriate person, more often than not, the Tracker. The Manager, however, does not tell people what to do and when to do it. This is done by the Customer and/or the User Stories themselves.
  • Gold owner: The Gold Owner is the person who funds the project. This could be the customer, but not necessarily so.

Some of the extreme programming roles, as described above, can be combined, but some clearly cannot.

The customer, for instance, cannot be the Programmer as well. The Programmer and the Tracker, similarly, cannot successfully be the same person.

The extreme programming roles are defined clearly enough so that there is no confusion and created for maximum flexibility and efficiency.

Drawbacks of Extreme Programming

While proponents of Extreme Programming paint a rosy picture, the fact of the matter is that Extreme Programming, as the name probably suggests, is Extremely Difficult to implement. Facets of Extreme Programming can be incorporated into projects more successfully than completely adopting XP.

Some of the negatives of Extreme Programming are:

  • It is found to be more effective in smaller groups. Its efficiency in larger groups is contested, and a better option is to split extreme programming teams so that groups are smaller.
  • One of key features, pair programming, does not work well in many cases. Complex coding might require two heads, but not all tasks may require two people, with the second person being dead weight. In fact, pair programming, if one of the members is not in sync with the other, is one reason why Extreme Programming fails in many cases.
  • The dependence on the customer, to the point of suggesting an on-site resource from the customer’s side, can be deeply unnerving. It may also lead to interference, both real and imagined, during development.
  • It focuses on simplicity may make it very difficult to add to the current project, meaning a higher budget for even simple changes, which do not remain simple anymore.
  • The flat hierarchical structure means that the team should always be focused, and in the absence of a manager to corral divergent types of people. The extreme Programming team is entirely dependent on all team members’ emotional maturity, a factor that is not always dependable.

Even with these factors, it remains a powerful tool to be used for the right project, with companies reporting a manifold increase in their efficiency after adopting the extreme programming process. A developer-driven system, as opposed to Scrum, which is more of a process-driven system, Extreme Programming, or at least parts of it, can lead to a revolution in the way we develop extreme programming software.

Recommended Articles

This has been a guide to Extreme Programming. Here we have discussed the basic concept, activities, values, role, drawback respectively. You may look at the following articles to learn more –

  1. Extreme Programming (XP) in a Nutshell
  2. Quality Control Methods
  3. Haskell Programming
  4. Anagram Program in Java
quiz