Imagine this: A software development project for a new product, based on first-to-market advantage has just been spotted on your company’s radar. Traditional methods of extreme programming, 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: that involves creating short “sprints” based on the customer backlog of tasks. And then, there’s Kanban, which works on optimizing the pipeline of work. There’s also Extreme Programming, often abbreviated to XP, which focuses on amplifying the positive aspects of traditional programming models so they work to their maximum potential.
Extreme Programming 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 the aspects for software development.
Kent Beck was also the pioneer of test-driven development, which put use-case testing on the radar as an improvement over the way things were done then: writing lines and lines of code and then testing it. He was also one of the original signatories of the Agile Manifesto, helping shape the manifesto to change the way extreme programming software was written.
The five values of Extreme Programming based on Explained are:
Extreme Programming 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.
This is at the core of Extreme Programming. The methodology favours simple designs, not thinking too far ahead into the future, but focusing on the requirements of today, while making the program itself robust enough to add the requirements the future throws up.
This essential loop of going back and forth differentiates Agile systems in general and Extreme Programming in particular, from other software project management methodologies. The 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, so that changes can be implemented by the developers.
- From the client: This is an essential part of most Agile systems. Clients write the acceptance tests that the development is based on, and this forms the backbone of the development process. All iterations are also delivered to the client, for a periodic feedback.
- From the team: Once a new use case/story has been created, the team immediately reverts with 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.
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 the core of Extreme Programming: Be ready to jump, without a parachute if it comes to that! Look at this different style of project management, and be ready to be responsible, to renounce hierarchy and be responsible and work without knowing everything in the beginning itself.
Respect, the fifth value, was added later, and means 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 the communication between different stakeholders as well.
Activities of an Extreme Programming Project
Extreme Programming distinguishes four simple activities of a project. They are:
- Coding: Extreme Programming 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. Extreme Programming 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 to not merely 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, as well as the developers’, forms 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 an 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:
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 an internal planning of the teams, as to the tasks they will work on.
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 significantly improve the efficiency of code. This may not be suited to all development scenarios, and that is something to consider before signing up for Extreme Programming.
All code that is written 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!
Design Improvement (Refactoring)
XP projects, based on its feature of simplicity aims to continually improve upon the code that is written. 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. Makes it tighter and clearer. It is akin to editing a piece of writing, polishing it and making it better.
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.
This includes the standardization of all naming conventions so that its 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, so that it is 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, Extreme Programming 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 also jumps in to help when required.
- 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 are run by the programmers themselves.
- 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:
- Extreme Programming 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 the key features of Extreme Programming, 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 a dead weight. In fact, pair programming, if one of the members is not in sync with the other, is one of the main reasons 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.
- Extreme Programming’s focus 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, an Extreme Programming team is entirely dependent on the emotional maturity of all team members, a factor that is not always dependable.
Even with these factors, Extreme Programming 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.