Last week I finished reading the first edition of Extreme Programming Explained, written by Kent Beck. I explicitly wanted to read the first edition, that I purchased via AbeBooks, which is also the first book that appeared in the series of books on XP. I’ve read a couple of book reviews of the second edition on the interweb where some have stated that the second version is somehow less ‘extreme’ compared to the first edition. That’s why I went for the first edition as I wanted to learn from the ‘original’.
While it seems that Scrum and Lean are getting all the buzz in agile software development these days, why on earth would I want to pick up a book on Extreme Programming that has been written back in 1999? Well, it’s my current feeling that XP is the ‘core’ agile methodology. While there was some buzz around this software methodology in the late 1990s and early 2000s, it has never been commercialized nor pursued by hypesters, at least not on the same scale as Scrum and Lean. I’m not saying that Scrum and Lean are therefore bad and should be avoided. On the contrary! I’ve been part of a Scrum team for many years now where we’ve been complementing this project methodology with XP engineering practices like unit testing, continuous refactoring, continuous integration, etc. … . This has been working because of these XP practices, not the other way around. But what I’m seeing more and more lately are teams that are adopting Scrum without any of these solid engineering practices, especially in enterprise environments. Therefore I think it’s important to learn more about XP, which is one of the agile methodologies that somehow managed to preserve its values throughout these years without losing its balance. I’m with Uncle Bob when he states the following in his blog post on Bringing Balance to the Force:
“I, for one, consider the agile movement to have been inundated by a vocal and enthusiastic cohort of project managers, waving their scrum-master certificates, or their Lean and Kanban books. They have overwhelmed the original movement and changed it into something new. Agile is no longer about a balance between the technical and non-technical parts of development. Rather it has become a discussion almost entirely dedicated to non-technical issues. Agile is no longer about healing the divide, or closing the crevasse. The agile movement now represents one side of the crevasse.”
Anyway, back to the book review. I personally found this book to be a very fascinating read. It’s divided into three major parts:
- The Problem – This first section sets the stage for XP. The chapters in this section discuss the value proposition for XP while also showing the disciplines behind it. The four values of XP are Communication, Simplicity, Feedback and Courage while the fundamental principles are Rapid feedback, Assume simplicity, Incremental change, Embracing change and Quality work and the four basic activities are Coding, Testing, Listening and Designing. These values, principles and activities are broadly discussed throughout this section. Basically, here you’ll get a high-level view of Extreme Programming.
- The Solution – Given the values, disciplines and activities from the first part, the second section elaborates on the strategies and practices that make up XP. The practices discussed are The Planning Game, Small releases, Metaphor, Simple design, Testing, Refactoring, Pair programming, Collective ownership, Continuous integration, 40-hour week, On-site customer and Coding standards. The book doesn’t provide an explanation on how to do these practices. It’s more about why these practices are important and why they’re under the XP umbrella.
- Implementing XP – The third and final section of the book deals with a number of various topics like how to adopt XP, when to use it, when not to use it and what it takes from people that are part of an XP team. I personally got the most value from the chapters in this section.
Something that the author kept repeating throughout the book was the importance of how the office furniture is arranged for an XP project team. I never really thought about this, but after reading this book I’ve come to realize how important this can be. Being able to easily pair program and get the customer to sit with you can in fact be a game changer.
Here are some of my favorite quotes that I picked up while reading the book:
“No single action takes the life out of a team or a person more than being told what to do, especially if the job is clearly impossible. Primate dominance displays work only so long in getting people to act like they are going along. Along the way, a person told what to do will find a thousand ways of expressing their frustration, most of them to the detriment of the team and many of them to the detriment of the person.”
“So you code because if you don't code , you haven't done anything. You test because if you don't test, you don't know when you are done coding. You listen because if you don't listen you don't know what to code or what to test. And you design so you can keep coding and testing and listening indefinitely.”
“Code gives you a chance to communicate clearly and concisely. If you have an idea and explain it to me, I can easily misunderstand. If we code it together, though, I can see in the logic you write the precise shape of your ideas. Again, I see the shape of your ideas not as you see them in your head, but as they find expression to the outside world.”
“The difference is between playing to win and playing not to lose. Most software development I see is played not to lose. Lots of paper gets written. Lots of meetings are held. Everyone is trying to develop "by the book", not because it makes any particular sense, but because they want to be able to say at the end that it wasn't their fault, they were following the process. Software development played to win does everything that helps the team to win and doesn't do anything that doesn't help to win.”
I highly recommend that you pick up and read this book. It’s only 166 pages and a bargain on AbeBooks. By reading this book I learned a lot about agile software development and more importantly, how to strike a balance in customer collaboration and technical stuff. The book contains a tremendous amount of knowledge and wisdom. I sometimes had a very hard time putting it away as its also very nicely written. Two thumbs up!
