I’ve read Domain-Driven Design (DDD) a couple of times now and consider it the most influential book on the way I develop software. But I’ve yet to blog about it. It’s time to change that.

Firstly, serious developers and analysts simply must read this book. It’s the sort of book I’d demand be read if I owned a software organization, though (being generous) around half of the book is applicable to Analysts.

Before I read DDD the concept of a Domain Model was somewhat fuzzy, even after reading Patterns of Enterprise Application Architecture. So often I’d seen ‘Domain Models’ purely holding state. I’d joined teams late in the game that had developed ‘intelligent’ Domain Models, but how they got there was a mystery. Questions like:

• Why had this domain concept become a class?
• Why apply this pattern in the domain layer?
• What direction are we headed with the domain model?

…the answers were never clear to me. Often one technician on the team had the answer, but I didn’t feel empowered with the knowledge to act without their consultation.

DDD hits home the importance of Domain Models and presents infinitely more information than development guidelines like ‘objects should have both state and behavior related to that state’. My most significant learning from it is an approach for distilling real world concepts into software, concepts that linger in the mind of domain experts but never crossed the divide. I won’t go into detail here, but the book presents the essence of distilling those concepts - unifying the language used across roles and, more generally, throughout the team.

It’s now a rare day when a team member’s ear won’t be ringing to the sound of me stressing the importance of modeling objects on domain principles, rather than abstract, somewhat related or technical ones. Analysts directly contribute to assembling simplified object models and are on the receiving end of questions like ‘does this concept have a name?’, ‘is there a general concept that encapsulates these things?’, ‘can we break this thing down, what do you think it’s composed of?’, ‘how would you identify each of these?’.

From a requirements perspective, it’s shifted my focus from understanding the requirements and acceptance criteria in isolation to understanding the core domain; the business of the users. According to the Kano Quality Model, customers are delighted when they discover new and useful features, stuff they wouldn’t expect to see. Immersion in the domain is key to having this capability.

From a development perspective, it’s given me techniques to aid modeling the domain in software. They focus on keeping the software simple and reducing translation time between the software and the domain. Again, I won’t spell out in detail what’s best covered by the book, but it is the kind of stuff you can start practicing immediately, the majority of it transcends languages and is bound to be relevant for many years.

The book also offers solid advice to leaders on effective team structures and subdividing teams and domains. This ground is probably less explored than other parts of the book but it’s no less important. From my experience it is used less, quite simply, because changes of that magnitude requires organizational clout that is difficult for a team to ascertain.

Here’s a brief list of observations from my DDD experiences:

• I find myself spending more time thinking, less time doing while at the same time being more productive
• I’m more proactive in engaging analysts. Emotionally there’s less of a divide between developers and analysts
• The code is more consistent and easier to navigate. You are less likely to be able identify the code of an individual
• You fear changes to the code less
• You strive to the understand the business’ problems more and focus less on simply producing software
• Design discussions are welcomed and flow naturally, there’s often less friction
• Breakthroughs, refactorings that significantly simply the implementation, come earlier rather than later

Credit where credit’s due; this book is quite simply an excellent geek read. For more info see Domain-Driven Design.

Agility is not solely found in practices. Developers may implement stories, you may practice continuous integration, pair, practice TDD, DDD, <Any>DD - just because you do doesn’t make you Agile.

Actually I’m going to go out on a limb here with this: ‘Most organizations who believe they are Agile are actually far from it.’

The big thing that’s missing: Authority. Teams are often hamstrung by politics and power struggles preventing them from autonomous control over their practices and processes.

Another thing that’s often missing: Courage. The courage to try something for an iteration and learn from it. If a suggestion has merit why fear the consequences when engrained in your pschye is rapid feedback allowing you to try and try again? With rapid feedback teams should be thinking more of opportunity than consequence.

Can your team respond to change? Can you respond to the opportunity to improve by tweaking processes and practices? You may have the intellectual capability, but do you have the authority?

Putting lipstick on a pig doesn’t make it catwalk material.

Taking the authority to tweak processes for solving a problem away from the problem solvers is an excellent technique for building resistence and disenchantment. By doing this within a short period of time an organization will have guaranteed capability to hit the drink market with a new explosive product: ‘Bottled Frustration’.

The teams methodology will start conforming to that of the dictatorship imposed on them. Sure, the team can build Firewalls and Anti-Corruption Layers but the best they’ll do is practice ‘Agile in a Bubble’ - a virtual world detached from the reality of the organization.

In these environments the big challenge is to establish Trust with those imposing resistence. Building up a record of excellent delivery is great, but that’s little comfort when you’re the team trying to build that track record.

For mind in these cases your ability to justify your teams beliefs, practices and processes is invaluable. I’m surprised how few people appreciate the fundamentals of what they do and why they do it - if you lack the ability to defend what it is you do you are nothing short of a pawn in game played by others. So, knowledge and logic is one part of the justification effort - that’s your core arsenal. But how you deliver that is equally important - leadership and charisma play a massive part.

Knowledge can be learned. It would be nice if that were true of leadership and charisma.

For those lacking these traits, ‘Bottled Frustration’ and idealism can come to fore radiating fanaticism. At best in these cases the team will appear to be moving forward, but in reality the escalator that is the organization slowly moves them backwards.

I’ve been lucky enough to have experienced a number of development methodologies in my time, ranging from straight forward Waterfall, to a more iterative RUP style, to a pure-bred XP style. Along the way I’ve been reasonable enough to be open minded and accept other practices. Granted, I don’t think there’s even been a time when the transition was easy. There’s always questions, always pro’s and con’s, and there’s always my opinion regardless of what an organization chooses to dictate.

What’s made my transitioning between the methodologies more difficult is my relative stubbornness – an attitude that was prominent until I hit my XP days. It dissipated (although not completely) then, gratefully loosing the battle with the XP evolutionary mindset.

But, I digress. My point is this; my experiences have led me to believe, without doubt, that XP is is the best methodology I’ve worked with. From a purely selfish point of view, it acts in my best interest by allowing me to focus on what I’d like to do best – learn and develop software. From an organizational point of view, it acts in it’s best interest by delivering higher-quality, maintainable applications, with scope flexibility that is guaranteed to deliver what the business wants - I’m not suggesting other processes don’t do this, but they just don’t do it efficiently as XP.

So, with these beliefs in mind, I find myself working for an organizations that doesn’t practice XP. In fact, I’m fairly certain that before I arrived they had very little idea about the methodology and even it’s practices. Staying true to my beliefs, I’ve discussed a number of solutions to a plethora of project issues with the ‘Powers That Be’, and it’s no coincidence my suggestions have been grounded on XP practices. To date this adventure has taught me that my stubbornness is definitely no unique trait – no surprises there. Importantly, I now appreciate that XP is much easier to teach in a ‘viral’ form – it’s so much easier to understand it’s benefits by actually doing it. The tricky part is getting an organization over the initial hill and convincing them to test drive a practice or two.

I find arguing XP’s theoretical side is easy. For mind, the theory of XP is simple to understand. After all it’s based on long-standing, tried and true, common sense, industry best practices. So the theory isn’t the issue. Getting people to understand how the theory works in practice is. Here’s some highlights of resistance I’ve encountered to date:
- That sounds great, but in the current state of play, we don’t have the time.
- I’m not comfortable with Pair Programming - it doesn’t seem natural, I can’t work with others looking over my shoulder.
- I’ve never had to update my Big Upfront Design after an Implementation. I’ve always been right upfront.
- I believe it’s in a projects best interest to produce reams of documentation. They communicate important messages to a great variety of audiences.
- I don’t believe Practice X works on large projects or in large organizations.
- XP is too radical and promotes shortcuts.
- No thanks, I know this other methodology works for me.

Some of these points are plain old ludicrous and easy countered, others suggest you need to produce some empirical evidence to back up a claim, others still are a strong indication of a closed mindset. In these latter cases I find there’s no alternative but to walk away from the discussion with your objections duly noted – especially when your dealing with decision makers. I find the hardest thing about dealing with a decision maker is when it comes to opinion - theirs counts, yours doesn’t. You need to resort to hard evidence and fact, while, on the other hand, their opinion is good enough reason for them. I can appreciate that they’ve earned that position, but it serves to occasionally obscure them from seeking out and making better decisions. In some cases the decision makers can suffer from Sinatra Paralysis, they just want to do it their way and will naturally resist, finding ways to keep their vision intact. In other cases they can adopt a Whiteboard Approach and rarely practice what they preach, not feeling any pain at ground zero.

Still, regardless of the many setbacks, I’ve gained many positives from the experience of putting forward arguments for adopting XP practices. My positive opinion of it has been re-enforced in the search of counter arguments and justifications. I’ve been able to see, in practice, how it is very capable of solving the many problems more traditional methodologies can and do encounter. I’ve also been able to gain a greater appreciation of the decision makers reasoning and motives.

So, even though most of my suggestions fall on seemingly deaf ears, I pledge to continue making them – I see it as a win-win situation for me and the team regardless. It’s a win for me to put an argument forward and it’s a win for the team to at least considers potential process improvements it offers, regardless of their mindset. There’s always hope that they will one day both hear and listen.

I remember prior to starting my European expedition, The Trigger told me of a proverbial software development jungle on the free market. He believed it was very unlikely I’d uncover a project with a pro-XP mentality. At the time I agreed with him, but I was hopeful it wouldn’t hurt too much. Well Andy, you were right - and it doesn’t hurt that much, well….maybe a little
P.S. Many thanks to the organizers of the recent XP Benelux Day for re-charging my interest. It’s good to know that there’s plenty of other XP practitioners in the region.