Books for software engineers and managers

Extreme Programming Explained

Extreme Programming Explained

Embrace Change

by Kent Beck

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.

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:

  1. Problems in software are regularly changing, making adaptability a key feature of successful approaches
  2. 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.

Extreme Programming Explained