Dear Junior
At the DDD Summit a year ago there was an interesting discussion about how we motivate doing Domain Driven Design. We noted that one of the classical argument have been "proper domain modelling will make maintenance and further development easier". This is more or less saying "spending a lot of time now will save us time later", which is basically a bogus argument. If we are doing DDD it should be because it saves us time now.
The general agreement last year was that domain modelling actually speeds us up now, so doing domain modelling saves time - and thus we should do it to benefit for the work the current sprint.
I have had this discussion in the back of my head during the last year, trying to keep my eyes open for how this could be the case - how doing more work actually could result in less work.
At the DDD Summit this year I had a really rewarding discussion about this with Steve Bohlen, sharing our experiences from the passed year.
If you do not do domain modelling, you will view the story to implement from a technical perspective, and then there is probably an obvious way to do it. The approach will include activities A, B, C, D, and E - so write down those as tasks, post them on the sprint board and start working. How could extra domain modelling save us time? Will it really make us work faster?
In order to make sense, let us think about it in the opposite direction. Efficiency can be seen as working fast. However, it can also be view as "maximising the work not done", which is mentioned in the Agile Manifesto as the principle of simplicity.
One of the important mechanisms of domain modelling (if done right) is that it opens up options. In a domain modelling session you challenge yourself and the team to think about the problem in different ways, and a good modelling session might well result in three different ways of thinking about the problem - and thus generating three different solution.
Evaluating three different solutions might give you that first include activity A, C, E, and F. Second include B, F, and G. Third include A, B, D, F, H, and I. Now of these some might be worse than the "technically obvious solution". In this case third solution is probably worse; six activities instead of five.
However, the work to implement the result of the different alternative is not the sum of the alternatives , it is not even the average of the alternatives, it is the minimal effort - the tasks for the easiest solution found. In this case, the simplest solution is the second, only requiring three activities.
In general, the simplest solution found during the domain modelling is most probably easier that the solution that was obvious from the technical perspective. A small investment in opening options was well outweighed by finding a easier solution. So, we save time not by working faster, but by working smarter.
And just to be clear - we are talking about a small investment in domain modelling, like a few hours or a day. It is not about a "phase of the project" were you spend weeks in day-in-day-out workshops and discussions.
During the year my colleague Daniel Deogun had a wonderful example of this happening at our client. At the sprint planning the team was convinced that they knew how to implement the story at hand. However, just to open up options, Daniel kidnapped the team for a two-hour domain modelling session. During that time they found new ways of looking at what they were building. So they ended up not touching the code they had envisioned to change. Instead they changed somewhere completely different and the amount of work shrank from being a dominating part of a sprint to be a few half-days of work for a few team members. And that insight was driven by asking questions about the domain - trying to phrase the answer in different ways.
So, doing more work to save time might seem very unintuitive. However thinking about it as finding options to "maximise work not done", I think it makes sense. In a way, what we are avoiding is the sadness of a really fast boat sailing at high speed in the wrong direction.
Yours
Dan
ps BTW, Steve and I had more interesting discussion around this topic, but that will need to be the topic of another letter.
