Ever since the start of factor10, I have considered Extreme Programming (XP) to be one of our cornerstones. So, as part of the onboarding for newcomers, we thought it would be fun to have a book circle about Kent Beck's “Extreme Programming Explained: Embrace Change (second edition)”. Everyone else jumped on board as well. Such a lovely read; I realize it’s some kind of record in confirmation bias. :)
On re-reading it now, one thing that made a strong impression on me was something Kent wrote on page 53, at the end of the chapter called “Primary Practices”:
The big payoff of XP comes once these practices are firmly in place. Then comes the big step forward: business relationships that directly support further perfection of software development.
That sounds a lot like that Domain-Driven Design (DDD) would fit perfectly after XP, not as another cornerstone next to it which is what I have thought in the past.
It resonates very well with me as, time and time again, I’ve seen that only the most tech-savvy developers find DDD interesting. The newcomers couldn’t care less, if I may generalize. Yes, I know that all generalizations are wrong. ;)
So you have to be fluent with the tech first, standing on solid ground. Probably it’s more correct to split between tech and XP and say that become fluent with tech first and then XP. After that, DDD.
As I write, it occurs to me that I have often wondered why schools don’t teach the students XP practices from the start in every course where it would be helpful. Why do we have to re-program skilled people? I don’t have the answer, but it’s probably a decreasing problem.
By coincidence, I read the foreword by Eric Evans to my book “Applying Domain-Driven Design and Patterns” and found the following section which further explains it (page xxix):
Ironically, to render clear and useful domain concepts in software, to keep them from being suffocated under technical clutter, requires particularly deft use of technology. My observation is that those with the greatest mastery of technology and architectural principles often know how to keep technology in its place and are among the most effective domain modelers.
I recognize this situation in myself right now, in the project I’m currently spending most of my time on. I’ve worked a lot in the past with the main programming language of the project, but it has evolved a lot since I last did real stuff with it. So now I have to fight to get things working, and much of my focus is currently spent on that.
So, XP and DDD aren’t cornerstones; they are more of a stack. That fits well with putting Theory of Constraints (TOC) there as well. Not as a cornerstone, but on top of the other in the stack. Something like this:
- Understand development, with a passion for delivery
- Understand how to evolve development, XP
- Understand business, DDD
- Understand how to evolve business, TOC
This article was originally published on LinkedIn. Join the discussion and read more here.