I’m lucky enough, at least in my opinion, to work in a team that values extreme programming practices. It’s not true of every team at eBay, but it’s a growing trend. Extreme Programming (XP) is something I’m comfortable with, and I hope to help other teams see the benefits, and start to put some of the practices into play.
As part of helping other teams, I thought it’d be prudent to refresh my knowledge of Extreme Programming. To do this, I started with the “white book”, Extreme Programming Explained by Kent Beck. It’s an old book; it’s now more than 15 years since the first version was published. Is it still relevant today?
In short, yes. As I have already alluded to, there are teams that are still developing software in the same way they were 20 years ago. Practices such as Continuous Delivery and Test Driven Development are still not adopted in every company.
This is why this book is still relevant, and should be on every software developers reading list. It’s a quick and simple read, outlining the methodology, principles and practices that go together to make XP work. It’s a great introductory text, leaving the reader with no doubt that there’s another way of building software products.
The first part of the book explores the key values and principles behind the methodology. It then goes on to lay out a set of practices which support these values and practices and gives the reader some ideas of how to get started. In this chapter in particular, Beck is clear to point out that it’s not easy to apply all XP practices to existing teams. Beck’s suggestion is to pick one thing you want to achieve with the team and and use XP to achieve it. Once you’ve done this once, reapply XP to achieve the next thing. Before you know it, you’ll be applying most of the XP practices.
Beck does point out that there are better practices to start with than others. For example, starting out with Continuous Deployment without first addressing your defect rate leads to more problems and the eventual feeling amongst the team that XP doesn’t work.
The book then moves on to discuss how teams work together, explaining how testers, interaction designers, product managers and, of course, developers work together to support the XP methodology. It also addresses how XP scales to larger teams and organisations.
In section two of the book, Beck shows how successful ideas from different industries back up the philosophy of XP. These war stories reinforce the idea that the core values and principles of XP will work for software development. It also addresses the issue of applying XP to offshore development teams. This adds to value of the book, as it could have just focussed on the teams which are co-located, where it is easier to apply XP.
In summary, I’d recommend this book to anyone who is working in Software Development. Even if you’ve been applying some of the practices in your day-to-day development, it’s a useful read to reinforce how the practices support each other. If you’re not already practicing XP, then the book will help you understand the benefits of the practices, and give you the motivation to want to apply them.
