Extreme Programming Explained

Extreme Programming (XP) was one of the oldest topics I wanted to dig further into. Not because it is so widely known and understood in my proximity, but rather the opposite. I cannot name even a single person I know whom I could talk about XP with. On the other hand, industry leaders I trust and respect regularly refer to XP. One of the most notable ones is Robert C. Martin. So I decided to wait no longer and bought the book Extreme Programming Explained by Kent Beck, the father of XP. It looked for a perfect choice.

The book left me with mixed feelings. I hoped it would give me a better explanation of the famous three circles of XP practices. To put it differently, I was expecting a complete framework in which everything is connected to everything else, ultimately resulting in a very comprehensive, interconnected system. Something similar to Scrum, for example. But XP is more a bunch of loosely coupled values, principles and practices as it turned out. They aren’t that strictly connected or dependent on each other. Some of the practices were way beyond my expectations, and I’m still digesting them, like the “Pay-Per-Use”. This practice, which occupies less than a page in the book, argues for choosing a pay-per-use business model for our software. I didn’t need to finish the book to know it doesn’t even mention the famous three circles of XP practices. But is it a problem?

I know now that my confusion had two reasons. At first, I approached the book with preconceptions about what it was about, obviously. On the other hand, XP is old, even older than Agile itself, and it has evolved since the author published this second edition of the book in 2004.

Despite all of the above things, I really liked the book and the XP itself. I see now why Robert C. Martin refers to it as the most defined process, or the one that defines all of the parts of Agile. The XP practices cover the full spectrum of the software development process, including business-facing, team-related, and engineering-related practices. They are just not very interconnected and organised in “those” circles yet. And what better illustrates the full spectrum than the Pay-Per-Use business model at one end and the extent to which we shall lean towards the other during pair programming at the other end.

This book is an excellent choice for those who are struggling with Agile but do not know why or what their project is missing. Very likely some practices from XP.

What I liked the most:

• It can be the secret ingredient for successful Agile projects
• It covers the full spectrum of the software development process

What I didn’t like that much:

• The practices do not form a very cohesive system. Each of them can live in its own bubble
• It feels here and there a bit outdated, which is fair for a 2004 published book