by Kent Beck, Cynthia Andres
In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.
This book is the “manifesto” of Extreme Programming, an implementation of Agile offering several good ideas on the practice of developing software - when applicable :-)
As with Agile itself, the book presents a “reorganization” of empirical findings of the authors, defining a set of “Values” and “Principles” (one before the other) to be used as a guide, and offers afterwards several practices (further organized as primary and corollary) to be taken gradually and with intelligence.
The intellectual honesty of the book is much appreciated - it is not meant to be a “bible” or a blueprint of some sort, but it acknowledges that reading the circumstances is paramount in defining a set of practices for a team.
Much less “situational” are values and principles, so defined:
- Economics. An equilibrum between value of time and the value of “system options” (ie possible personalization) must be found.
- Mutual benefits
- Self-similarity. For example of what they mean here, see the “Fractal Architecture” of Elm and Cycle.js
- Diversity. The team must consist of people with different skills
- Opportunities (that often arise from problems)
- Failure (as an important learning opportunity). Trying and testing possible solution can be better than reasoning about them.
- Quality (not to be considered as something to control. Lower quality doesn’t mean going faster)
- Baby steps (to be applied in the implementation of XP programming itself)
- Accepted responsibility. Authority must take responsibility of the decisions.