I have read many software development books, but there are only a handful that had such an impact on my life that they fundamentally made me look at software development differently. Today I have to add Kent Beck’s Extreme Programming Explained 2nd Edition to that elite group.
The physical book looks deceptively thin - one hundred and sixty odd pages with an easy text and thick margins. Firstly, the thick margin were useful because they are now covered with notes and between those pages I believe there is a message worth gold.
Kent Beck’s explanation of the relationship between Values, Principles and Practices is as far as I am concerned a required reading for software developers going forward. I have seen teams struggle, debate and argue about various practices and whether they are good or bad - in the past I would have a hunch or could say what I had seen work in other teams - but for the very first time I feel I can now justify one practice over another, one tool over another and explain why one is fundamentally better than another.
The rest of the book continues to contain these gems that keep resonating with me - here are a few I underlined, but read the chapters related to get proper context:
- pg. 38 - Practices are theories
- pg. 38 - No matter what the client says the problem is, it is always a people problem
- pg. 40 - Cleanliness and order leave minds free to think about the problem at hand
- pg. 42 - On pair programming hold each other accountable to the team’s practices
- pg. 49 - Software has few certainties. The ten-minute build is as close as we get in software engineering.
- pg. 52 - XP teams work hard to create conditions under which the cost of changing software doesn’t rise catastrophically.
- pg. 52 - Without daily attention to design, the cost of changes does skyrocket
- pg. 53 - Refactoring is a discipline of design that codifies these recurring patterns of change
- pg. 65 - The five whys when establishing root cause analysis
- pg. 79 - Trust two metrics to measure the health of XP teams. The first is the number of defects found after development. The second metric is the time lag between the beginning of investment in an idea and when the idea first generates revenue.
- pg. 88 - The reward system and culture need to align with overall throughput instead of individual productivity for the change to stick.
- pg. 91 - The importance of time available
- pg. 92 - Plans and Prediction explanation
- pg. 92 - Ingredients to planning
- pg. 94 - On estimates… I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible
- pg. 95 - Many teams try to skip this step and go straight to a computerized version of the stories. I’ve never seen this work
- pg. 98 - 2 Defect Reducing Principles
- pg. 104 - Unfortunately, design in software has been shackled by metaphors from physical design activities
- pg. 108 - Part of incremental design is figuring out how to stage design improvements
- pg. 120 - If programmwers won’t pair or if they insist on owning code, have the ourage to fire them
- pg. 132 - Explanation on the incorrect assumptions on taylorisms
To sum it up, I know I am going to read this book many more times and each time there will be a deeper insight. Thanks to Kent and all those involved for this inspiring read.
Buy on Amazon
ISBN-13: 978-0321278654
