Thoughts on "Extreme Programming Explained" by Kent Beck
I've known about Extreme Programming (XP) since the early 2000's but had never gotten around to reading "Extreme Programming Explained", the original book on XP, by the creator of XP, Kent Beck. I recently just read the second edition which was published in 2005. It seems it holds up pretty well even after over a decade later.
- Testing early, often and automated
- Incremental design
- Continuous integration
- Short development cycles
- Incremental planning
"Extreme Programming Explained" is a fairly easy read. The chapters are short and generally easy to digest. I don't consider it a technically challenging book. That's of course not a knock against this book, the concepts agile and XP espouse I think are critical for effective software engineering.
- "Design is deferred until it can be made in the light of experience and the decisions can be used immediately."
- "Design done close to when it is used is more efficient."
- "Estimates based on experience are more accurate. It is important to get feedback as soon as possible to improve your estimates."
- "XP lets you adapt by making frequent, small corrections; moving towards your goal with deployed software at short intervals. You don't wait a long time to find out if you were going the wrong way."
- "Good teams don't just do their work, they think about *how* they are working and *why* they are working. They analyze why they succeeded or failed. They don't try to hide mistakes, but expose them and learn from them."
Also, one chapter of this book I thought was great was chapter 19. I'm not an expert or historian on socio-technical systems, but it's my understanding that a lot of the agile and XP approach grew out of the Toyota Production System (TPS), at least as far as eliminating waste in the production cycle.
In chapter 19, Kent Beck explains the benefits of the TPS process very clearly and it's easy to draw correlations to software engineering. As someone who has witnessed the challenges of organizational adoption of agile methodologies, I think starting off by having everyone read and discuss this chapter would go a long way in helping team members understand the benefits of the approach.
I particularly point this out because I think team member "buy-in" is the most critical component to true organizational change. Of course, to win others over, there must be incentive to change. I feel like Chapter 19 effectively and concisely explains this incentive.