Extreme Programming Explained
Embrace Change
Categories:
Favorite,
CTO,
Engineering Manager,
Tech Lead,
Star Engineer,
New Engineer,
Product Manager
How strongly do I recommend Extreme Programming Explained?
8 / 10
Review of Extreme Programming Explained
This book surprised me. I expected an outdated and dogmatic instruction guide. Something extreme. Instead I found a solid primer to agile development based on principles and basic practices, written in a chill conversational tone.
Extreme Programming Explained is a good book for people and teams that want to embrace agile, know some of the practices, but struggle because they haven’t yet connected those practices to underlying principles.
Top Ideas in This Book
- XP is just what we call best practices now: small batches, test automation, CI/CD, high deployment frequency
- Favor continuous flow over discrete project phases
- The project management triangle in software is Time, Cost, and Scope with time and cost usually fixed
- Especially under stress teams need to rely on their principles and practices, avoiding even temporary regression into bad behaviors
- Unfortunately software development is plagued with construction metaphors
- Code and tests can be written in either order, but XP generally prefers Test Driven Development
- Most software development is highly wasteful, building and maintaining features people do not use
- The course of improvement is neither smooth nor predictable
- Many people believe in iterative development in their brain, but real success requires feeling it in your gut
XP is just what we call best practices now: small batches, test automation, CI/CD, high deployment frequency
I expected XP to feel almost religious and perhaps in 1999 it did feel highly opinionated. But today, the areas XP embraces are just considered best practices.
Favor continuous flow over discrete project phases
Discrete project phases make us feel secure because they promise predictability. But that predictability is an illusion.
In practice, we want continuous flow of work through the system and that requires cross-functional teams with limited external dependencies.
The project management triangle in software is Time, Cost, and Scope with time and cost usually fixed
The classic project management triangle includes Time, Cost, and Scope. At the center is quality.
The trouble comes when developers try to negotiate quality. Even senior level developers make this mistake. Instead they should focus on managing scope, time, and cost, in that order.
Especially under stress teams need to rely on their principles and practices, avoiding even temporary regression into bad behaviors
When projects are running behind or additional scope is added, teams express stress and frequently revert to past unsuccessful and unproductive behaviors.
In these stressful environments is when teams need to trust their training the most.
Unfortunately software development is plagued with construction metaphors
Construction is different from software in two major ways:
- Problems in software are regularly changing, making adaptability a key feature of successful approaches
- Construction has far tighter constraints
Unfortunately many practitioners and stakeholders still think about software development using the same mental model as construction, resulting in misalignment between the problem and approach.
Code and tests can be written in either order, but XP generally prefers Test Driven Development
Beck mostly argues for TDD but accepts either order. More important is ensuring that quality tests are written.
Most software development is highly wasteful, building and maintaining features people do not use
One disheartening fact is that developers will spend a significant portion of their lives building systems that nobody uses.
Although not a stated goal or principle, waste prevention and reduction is a secondary benefit of XP. In practice teams developing and releasing iteratively are less likely to build features nobody uses because the usage feedback loop hits earlier and more often.
The course of improvement is neither smooth nor predictable
Teams implementing XP or any agile framework should expect growth in waves with lulling periods between.
Many people believe in iterative development in their brain, but real success requires feeling it in your gut
I’ve interviewed a lot of software engineering candidates who tell me they believe in automated testing, but have never really done it. That’s a good start. But doing it for real is what makes you a true believer.