Extreme Programming (XP) has been one of the most polarizing and most hyped programming paradigms in the software industry.

In a nutshell, two developers share a single computer; One (called the driver) does the actual coding, keeping the focus on the piece of business functionality that’s being written, while the other (called the navigator) observes, keeping the focus on the business problem they are solving and making sure all ends are covered. In other words, the driver has a microscopic and the navigator has a macroscopic grasp over the development.

XP is a full-fledged development methodology with incremental releases, collective ownership and daily stand-ups. Find more info here.

We got the chance to try it out for a few weeks. XP is certainly not for everyone, but based on our experience, we figured that XP would work well for you:

When requirements are not written in stone

XP works well (perfectly in fact) when the functional areas need more exploration and involve a lot of thinking and creativity.

If the exact requirements are not clearly defined beforehand and you have to search for the optimal solution to your client’s business problem, XP is for you. It will take you and the client on a journey of learning together.

When there’s good chemistry within the team

XP provides a natural environment to bridge differences: Think of a seasoned developer working with a junior colleague. Since XP mandates that there should never be a coach-student relationship, the work takes place in the everyone-is-in-the-same-lost-boat way with no one looking up or down.

As such, XP helps the junior learn fast and acquire new skills by closely observing how the experienced developer approaches the problem, designs and writes (quality!) code. Simultaneously, the experienced developer gains insight into the junior’s approach, allowing him/her to understand a younger generation’s perspective and draw from their knowledge.

So for XP to work, you need good chemistry in your team where hierarchy is replaced with open-mindedness and desire to learn.

When it’s OK to get noisy

We figured that pair programming works best when there are open or “unfiltered” communication channels within the pairs. There should be mutual trust and respect among the whole team, however at the same time, all team members should be comfortable with differing opinions.

Some of the more reserved developers might find the process somewhat uncomfortable at first, but, in our experience, this will improve if you can create the environment grounded in trust and consistency.

When you can keep the big picture intact

XP demands you to write minimal code. The navigator and the driver pair focuses on two levels of abstraction, still scoped on the piece of functionality defined by the task they are working on. This can make it trickier to keep an eye on the overall system architecture which can then cause serious architectural / design issues at the later stages of the project.

You must have enough capacity to keep an eye on the big picture throughout - including the code, the functionality and the architecture - while the product is slowly shaping up.

When you can afford to say ‘no’

Committing to XP without trying it first is too risky. Implementing XP can be smooth if your team culture is ‘open’ (or openable). However, if your team follows more of a traditional setup with strict workflows and if they have developed strong opinions on how things must be, then XP will be quite a challenge.

Other than the team, your management should also adopt to XP and have a realistic view on the risks involved.

Try ‘pair programming’ as a pilot project first. If it shows the right signs, you can go XP all in. It’s a love/hate thing: either it will do wonders for you, or, will fail miserably.

Verdict

The primary justification of XP, as proponents insist, is the cost curve - i.e. high-quality logic / code that comes out from pair programming, saving a lot in the long-run which is otherwise spent on maintenance and support.

Is it truly the case?

Though the time we tried XP is not long enough for a thorough analysis, we can confidently say that in terms of the improvement of quality and the time spent, it was well worth it.

...

What are you experiences, questions or comments on XP?

---

---