Danilo Sato

It’s been a while since I read the 2nd Edition of “XP Explained” and I really enjoyed the emphasis on separating practices from values and principles. If you try to map the original 12 XP Practices to the new primary and corollary practices, you will notice that it’s not a one-to-one map. And that’s great! Practices are good when you are at the Shu level of learning, but they should be tailored to specific situations, and understanding the underlying principles and values is what will help you do that.

Besides Pair Programming and Test-Driven Development, most of the original XP practices are distilled in more than one practice in the second book. Refactoring and Simple Design are better exposed as Incremental Design, while the Planning Game can be recognized in a list of practices such as: Stories, Weekly Cycle, Quarterly Cycle, and even Slack. Although Coding Standards are not explicitly cited as a practice, you can see its importance when reading about Shared Code and Single Code Base. But you will miss one practice in particular from the first book: the System Metaphor.

The System Metaphor was probably the less adopted practice and usually one of the hardest to explain. If you’re able to express and design your system in a shared metaphor such as “Payroll is like an Assembly Line”, you will see the benefits of this practice shining through: communication with domain experts will be easier and the gap between domain model and implementation will become much shorter. But as it turns out, it is not easy to find a useful metaphor for every system.

If you miss this practice from XP and is looking for the underlying principles behind it, I strongly recommend reading Domain Driven Design, by Eric Evans. Striving to find an Ubiquitous Language to bridge the communication gap between developers and domain experts, and isolating complexity in a rich domain model are goals worth fighting for. In Eric’s words:

 

System Metaphors are not useful on all projects. Large-scale structure in general is not essential. In the 12 practices of Extreme Programming, the role of a System Metaphor could be fulfilled by a Ubiquitous Language. Projects should augment that language with System Metaphors or other large-scale structures when they find one that fits well. 

 

Other patterns for large-scale structure are discussed in the book, as well as a lot of other precious material. So if you still haven’t done it, go read the book!