Why is Extreme Programming "Extreme"?

Many people who are unfamiliar with XP may think that "Extreme Programming" involves programmers relentlessly coding without a break, following a methodology that aims to squeeze maximum productivity out of them. It's the dream of many old-school CEOs.

However, that couldn't be further from the truth. What XP actually aims to take to the extreme are certain practices that primarily focus on communication between the business and development areas, which was often overlooked in the early days of software engineering.

When Kent Beck coined the term, he probably envisioned that the extreme aspect should be the communication between the client and the development team. To such an extent that he emphasized the good practice of client involvement on a full-time basis. The client had to choose one or more representatives who could effectively communicate with the development team, participate in the team, and even contribute to the definition of acceptance tests for the system.

Putting emphasis on people (a concept that in the agile world has sometimes been given New Age connotations) was simply a counterpoint to the classic focus on processes in pre-millennium software engineering.

Yes, adopting this people-centric approach and reflecting it in both the values and principles of XP required defining a set of practices aligned with them: pair programming, collective code ownership, sustainable development processes that involve humanly manageable working hours---these are all practical applications of the principle of "Humanity," the first principle described by Kent Beck in his famous book. The order he chose was not accidental.

In the process of extreme programming, clients are involved in specifying system requirements and even setting their priorities. This is important because requirements are no longer specified as a list of functions. Now, the client, along with the development team, engages in discussions about scenarios, which are then translated into a series of story cards. From there, the development team focuses on implementing each of these cards into future software deliverables. These deliverables naturally include all the acceptance tests for the system and the tests already in place for previously implemented stories (there's no middle ground here).

A user story card is as simple as a card with a title and a description. Of course, at the time of writing, the requirements may still be quite vague. Once written, the development team must be able to break it down into tasks, estimate the effort and resources needed to generate a deliverable.

During this process, the client prioritizes all the cards for the business area. The focus is primarily on those that can provide immediate value to the client, assuming that this way value can be generated practically from the beginning. Throughout this process, the client resolves many of the doubts raised by the developers.

However, this requirements elicitation process is not as rigid as it is in the waterfall lifecycle. As we know, requirements change, and when they do, they affect the stories that have not yet been implemented, which need to be reviewed or discarded. If changes affect already delivered stories, a new story card is generated, reintroduced into the priority queue according to the previously explained process.

XP is, therefore, a redefinition of old development cycles toward more iterative models. Because, as we know, in any development, unforeseen changes arise and tend to degrade the software structure. XP tries to implement improvements as soon as they are detected, as well as continuously detect them.

Naturally, to achieve this, the software must be easy to understand and modify whenever new stories need to be implemented. And you can't imagine the number of practices that XP proposes to achieve this goal. But perhaps the most important ones are those that define how to test the system.

For XP, testing is one of the most important aspects.

Keep in mind that, being an iterative development, we no longer have a complete specification of the system as was the case with the waterfall approach. Now, we have to rely on a system for testing the software that is, let's say, more "informal." However, not informal in a negative sense, but in the sense of adopting an approach focused on reducing the probability of each new software increment introducing errors into the previously generated software.

This is where TDD, the crown jewel, comes into play.

Writing tests before developing a functionality (where functionality can be each of the tasks into which a story is divided) greatly reduces problems of developers misinterpreting requirements and inconsistencies in interfaces.

It also improves communication with the client by involving them in the generation of acceptance tests, which define that the system functionally meets the client's expectations. The tests become just another component of our software that is executed independently.

The topic of testing can be one of the most powerful aspects of XP but at the same time one of the most complex. From my experience, the greatest complexities are focused on three aspects:

1. For acceptance tests, they require significant commitment from the client---likely on a full-time basis. Not all clients are willing to make such a commitment.
2. Some tests, especially those involving the user interface, can be as painful to write as a toothache.
3. Programmers always prefer programming functionalities over writing tests. Sometimes it's a challenging task to convince them that it's important to apply the same level of excellence when writing tests as when implementing functionality, and above all, not to succumb to the temptation of leaving them halfway by avoiding the implementation of exceptional situations. Properly implementing tests is as important (if not more) as implementing a task correctly.

So, returning to the initial question:

"Why is Extreme Programming Extreme?"

The answer is: for many reasons, which can be reduced to the idea that the methodology takes the beneficial elements of traditional software engineering practices to "extreme" levels, especially when it comes to testing.