The phrase “extreme programming” sounds exciting and a little dangerous. It may call “extreme sports” to mind, but it isn’t as dangerous as water skiing through the rapids. Although extreme programming does need willingness to depart from tried and true paths.
Extreme programming (or XP) is a variety of the Agile approach to software development. As the name suggests, it pushes certain ideas to the limit. It’s not for everyone. But for certain projects and the right kind of team, it can produce rapid results. That too in a constantly changing environment. It’s based on a few simple rules and practices. If you’ve worked with Agile teams, you won’t find it completely unfamiliar.
The 5 essentials of extreme programming
XP is built on five ideas that inform every aspect of its development process: communication, simplicity, feedback, respect, and courage. Let’s look at how each one applies.
Communication
Everyone is a member of the team: project managers, developers, testers. They constantly communicate with each other and with the customer. There’s a daily standup meeting for status updates. The aim is to avoid surprises and identify issues quickly.
The customer gets frequent updates on progress. This is a consistent practice throughout the entire development cycle. Customers find out from the beginning what’s happening, not just when there’s something ready for them to test.
Communication may take the form of “pair programming,” one of XP’s most controversial ideas. The idea is that two people work at the same computer, checking each other’s work. Making a success of this requires the right personalities.
Simplicity
Keeping the steps simple is one of XP’s most distinctive features. A project starts with the simplest design possible. Rather than aiming to create an MVP as a first step, the process starts with a few lines of code that do something. Tasks are broken into small pieces, and functionality is added a bit at a time.
Instead of submitting a requirements document, the customer provides user stories. They don’t have to be full technical descriptions, just to say what needs to get done. The developers will work from that to create something. If the customer doesn’t like it, they’ll talk about what needs changing.
Feedback
Communication and feedback are closely related. The team is always focused on the customer’s needs. It provides usable code as frequently as possible and responds to customer reactions. Instead of finding out months later that it should have done something differently, it gets feedback within days or even the same day. Since each piece is kept simple, changing how it works isn’t onerous.
Respect
Everyone on the team is a contributor. Everyone gets listened to. Ideas get a hearing, even if they may seem silly at first. Ideas are evaluated by their worth, not by the seniority of the person presenting them.
The customer gets respect too. This can be hard when the demands seem arbitrary and excessive, but the tight feedback cycle helps avoid stress. Requests for change will come early in the cycle, before the team has invested too much effort and pride in making things work a certain way.
Courage
Respect and courage on a team go hand in hand. Everyone takes responsibility, and people don’t fake progress. If there’s a problem, the people responsible own up to it. They don’t get blasted, but they’re expected to do what’s necessary to fix it. This can include asking for help.
Courage can mean discarding a bad idea or a bad piece of code. The aim is to meet the customer’s needs, not to prop up sunk costs. Trying out a new approach is sometimes the best way to deal with a persistent problem.
Where XP works well — and where it doesn’t
Certain scenarios especially lend themselves to extreme programming. If the requirements aren’t fully clear at the start, it can work better than drawing up a detailed spec. Situations where the functionality will keep changing and never settle down are good candidates.
It’s necessary to work closely with the customer for extreme programming to succeed. Customers need to understand that they’ll get early prototypes and constant updates. They need to provide constant feedback.
Some customers want to submit a set of requirements and get a product with little communication in between. An XP team may interpret this as satisfaction with whatever the code is doing. If the customer comes back months later with a long list of changes, the paradigm will come crashing down. Everyone will be frustrated.
The team has to be the right kind. Developers who are used to working alone may not fit in well. If the team is geographically distributed, making XP work will be hard. A strong commitment to working as a team is necessary.
The choice of development processes depends on many factors. The company culture, customer requirements, and team members may be conducive to extreme programming, or not. It’s one of several options, not a dogma to follow in every situation. Team members who are new to the paradigm should get training before plunging in.
There are other Agile software development methodologies such as Scrum & Kanban that would be more appropriate in certain cases.
