Updated April 19, 2023
Introduction to Extreme Programming
Imagine this: Your company’s radar spots a software development project for a new product based on the first-to-market advantages. Traditional extreme programming methods, where the client knows “exactly” what they want, are out. Your small team comprises young professionals 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, the hugely popular Scrum 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, or XP, focuses on amplifying the positive aspects of traditional programming models so they work to their maximum potential.
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, the pioneer of test-driven development, put use-case testing on the radar to improve workings by writing lines and lines of code and testing it. He was also one of the Agile Manifesto’s original signatories, helping shape the Manifesto to change the writing of powerful programming software.
Values of Extreme Programming
The five values of Extreme Programming are as follows.
Communication
It is independent of extensive documentation. Experts suggest Extreme programming documentation only when necessary. So the methodology relies heavily on communication between team members and users.
Simplicity
It is at the core of Extreme Programming. The methodology favors simple designs, not thinking too far ahead into the future but focusing on today’s requirements while making the program robust enough to add the criteria the end throws up.
Feedback
This essential loop of going back and forth generally differentiates Agile systems and Extreme Programming, particularly from other software project management methodologies. Continuous feedback can work in different ways, but they all work towards making the strategy more robust and reliable.
Feedback can come in different flavours:
- From the Program: Throughout the project development cycle, the code is vigorously tested 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 form the backbone of the development process. Deliver All iterations to the client for periodic feedback.
- From the team: After creating a new use case/story, the team immediately reverts to costing and timeline estimation, firming up requirements as they arise. In Extreme Programming, no person “owns” any code; therefore, feedback on one another’s code is encouraged within extreme programming teams.
Courage
It 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: Traditional extreme programming methods of management have bogged down software projects, 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! When adopting this management style, one should be prepared to be responsible, renounce hierarchy, be accountable, and work without knowing everything at the beginning.
Respect
Later, the fifth value of respect was added, which meant respecting others and oneself. It also implies respect for the written code and 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 critical activity. “Without code, there is nothing,” says Kent Beck, the founder of Extreme Programming.
- Testing: Code is just that unless tested. The methodology is obsessive about testing, using unit tests to confirm that the code is working and client-generated acceptance tests to verify that the code is doing what the user needs it to do.
- Listening: Listening, exemplified by the core value of communication, is an activity that requires the developers not merely to hear the clients but listen to what they want. Developing and business are two different things, and often, developers need help understanding the business case of a particular decision. The customer’s needs and the developers’ form the basis of the “listening” activity.
- Designing: In a software development project, the designing activity, often so essential and primary, is placed at the end. 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 limit the importance of designing. Instead, excellent 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
Some extreme programming practices, mapped to software engineering’s best practices, differ from generic Agile methodologies. Some of the rules are below:
1. Planning Game
It 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, and internal planning of the teams, as to the tasks they will work on.
2. Pair Programming
It 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 needed. The two people often interchange their roles. It has verified proof to improve the efficiency of code significantly. It may not be suited to all development scenarios, which is something to consider before signing up for Extreme Programming.
3. Test-driven development
Review of All written code happens unit-wise, i.e., Testing of each piece of code that can do something happens first. Extreme Programming places a lot of emphasis on Testing. It helps confirm that the code works so that it can be in contention for inclusion in the radical programming project. It is analogous to unit tests in school: Testing of small pieces of information takes place so that the teacher/student can make course corrections and does not flounder during the annual examinations!
4. Design Improvement (Refactoring)
Based on their simplicity feature, XP projects aim to improve the code written continually. Continuous improvement involves continuously improving the entire code (and sometimes the database). Refactoring does not add any functionality; it merely enhances the existing code. It makes it tighter and more precise. It’s similar to polishing and improving a piece of writing.
5. Simple design
In Extreme Programming, the addition of features takes place when specifically required. Even if the code currently working is very similar to the future requirement, the selection still depends on whether or not the user story is agreed upon.
6. System Metaphor
It includes standardizing all naming conventions so that we can decipher their purpose and function. For instance, the <NewUser> or <ReplaceDefaultAddress> operations can help any programmer understand their functionality. It 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.
Roles within an Extreme Programming Project
Like Scrum, it has a few designated roles within each project. Now, distinct people can only sometimes perform the parts, and a person can take on multiple roles.
The Extreme Programming roles are:
- Customer: Self-explanatory. The reason for the project. She decides what the project needs to do. She provides 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 inquiries to programmers at a set interval. Typically, he goes around checking the progress of programmers, offering help where needed in several ways: rolling up his sleeves and helping directly with the code, letting the Coach know, or setting up a meeting with the customer, as needed.
- Tester: Runs functional tests. The tester does not run unit tests, which the programmers themselves run.
- Doomsayer: As the name suggests, this 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 passing decisions taken during sessions to the appropriate person, more often than not, the Tracker. The Manager, however, needs to tell people what to do and when. The Customer and the User Stories themselves do it.
- Gold owner: The Gold Owner is the person who funds the project. It could be the customer, but not necessarily so.
Some extreme programming roles, as described above, can be combined, but some clearly cannot.
The customer, for instance, can be someone other than the Programmer. The Programmer and the Tracker, similarly, cannot successfully be the same person.
The extreme programming roles are defined enough for no confusion and created for maximum flexibility and efficiency.
Drawbacks of Extreme Programming
While proponents of Extreme Programming paint a rosy picture, Extreme Programming, as the name suggests, is Extremely Difficult to implement. One can incorporate Facets of Extreme Programming into projects more successfully than ultimately adopting XP.
Some of the negatives of Extreme Programming are:
- It is 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 more minor.
- One of the critical features, pair programming, needs to be improved in many cases. Complex coding might require two heads, but not all tasks require two people, with the second being dead weight. In fact, if one of the members is not in sync with the other, pair programming 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 real and imagined interference during development.
- Its focus on simplicity may make it very difficult to add to the current project, meaning a higher budget for even simple changes, which remain the same.
- The flat hierarchical structure means that the team should always be focused and corral divergent types of people in the absence of a manager. 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 for the right project, with companies reporting a manifold increase in 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 revolutionize how we develop powerful 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 –
