Domain-Driven Design vs Demo Driven Development, a case for the “Yes upfront design” approach

Modern software development project management styles, such as Scrum, are centered around short development cycles, a.k.a. sprints. Many organizations misinterpret this and take a “no upfront design” and a “get coding from day one” approach. To them, the theory goes that we don’t need to design a software solution. We start coding but in small increments. At the end of each sprint the demo of working software is shown to the product owner and stakeholders. The stakeholders give feedback, then we modify the application, and so on, until we reach the point when we can deliver a software application.

I call this misinterpretation of the Agile principles a Demo Driven Development. According to this misunderstanding of a methodology, the whole team is rushed towards this short term goal and encouraged to cut corners in order to have a demo ready for the end of a sprint.

This may seem like a good idea, it gets people focused on a common goal. Some may say that it gets them working harder during the sprint, as they have an achievable goal. Also, product stakeholders have a chance to give early feedback, and if the requirements have been misunderstood this can be rectified early on.

There are many other alleged benefits of this style of development and it has been gaining momentum in recent years. I think this method works to an extent in some situations: for a small project, for projects with a relatively simple domain, or where developers understand the domain well.

However, I suggest that this style of software development is inappropriate for medium to large projects or for projects with a complex domain.

Various studies, such as the Standish Chaos Report, show that more than half of software development projects are not successful.

As we can see, the larger the project, the more likely it is to fail. So if your project is anything but small, you have statistics working against you. In order to increase the chance of your project succeeding, instead of adopting these “get coding from day one” and “no upfront design” software development styles, I propose the adoption of a Domain-Driven Design approach, this approach is particularly beneficial for medium and large projects, or any project with a complex domain.

DDD is a software development approach coined by Eric Evans in his book Domain-Driven Design: Tackling Complexity in the Heart of Software, initially published in 2003. Since then it has been enriched by many contributions from an ever-growing DDD community of practitioners.

Before we examine how using the DDD approach would benefit your project let's explore in more detail this rival “Demo Driven Development” practice (as I call it), or rather examine its shortfalls.

But first, a funny slide (they told me to put one in every presentation):

French mathematician Emil Borel postulated The Infinite monkey theorem in 1913 which states that a monkey on a typewriter hitting keys at random for an infinite amount of time would produce complete works of Willam Shakespeare.

No upfront design

Agile in general, and Scrum in particular, prides itself on a “No upfront design” approach. The idea is that each sprint we bring an Epic or a few Stories from the Backlog into a sprint. We focus on building a small portion of the product at a time. At the end of the sprint, we showcase what we produced and the product owner and other stakeholders give us feedback, tell us what to change. By iterating from sprint to sprint, changing and rebuilding the product each time, eventually, we will end up with a complete solution. Hmm, this reminds me of something…

Yes, as you guessed, this sounds like: “If you have an infinite number of sprints and a team of monkeys you will end up with the desired software solution” 😃

Okay, we do use software developers instead of monkeys — so we do not need an infinite amount of time. However, this approach does add a significant amount of time to most projects. And for complex and large projects this will result in code that is known, in the DDD community, as “ a big ball of mud” or “spaghetti code”. The Constant Refactoring approach can help, but how many product owners and stakeholders actually allow it?

Start coding ASAP

After more than 20 years working in IT, the “Start coding from day one”, to me, is the biggest mistake one can make in a Software Development project. According to Domain-Driven Design principles, the developer's understanding of the domain gets distilled into code. In practice, this means that if software developers misunderstand the domain and requirements they will start building the wrong product.

It’s true that as a project progresses, after many iterations and sprints, developers will eventually understand what is required from them. Unfortunately, by this stage, they have created a mass of code that is poorly structured and therefore hard to change and maintain. This is the point where developers say to stakeholders: “We should really scrap all the existing code and rebuild this from scratch.” At which point managers start to look for some “good developers” to hire, which, of course, don’t exist 😃.

The problem was not in the quality of the developers but in the use of the wrong software development approach.

Domain-Driven Design

Luckily there is another way. You don’t need to perform the proverbial “Two years analysis phase” as is often presented as a pitfall of a Waterfall Methodology, nor do you have to start coding without any design. Instead, you can adopt a Domain-Driven Design approach.

Domain-Driven Design (DDD) is an approach to software development: a set of techniques, principles, and patterns used to aid in the development of complex systems.

The goal of practicing DDD is to handle complex scenarios with a systematic approach in such a way that domain experts (stakeholders, product users, etc.) and the development team (product owner, software architects, developers, etc.) can collaborate effectively with minimum friction. Typically, they gather around a whiteboard during a Domain Exploration Session and produce various types of diagrams by using a number of techniques provided by DDD. These techniques are beyond the scope of this blog and there are many resources on the internet to give you an overview.

Domain-Driven Design and Agile

DDD can be used in conjunction with Agile, after all, they are two different things. Agile is a project management methodology, whereas DDD is a set of techniques and approaches to software development. The main point I am trying to make in this blog is: Do not focus on demoing fully working software at the end of each sprint. Instead, you can demo various DDD artifacts that are the product of Knowledge Crunching sessions. For example, you could demo a Domain Story Diagram, an Event Storming sheet, a diagram of Entities in a Domain Model, a Bounded Context Map… All these artifacts can be demoed and reviewed at Sprint Review meetings.

This means that you can still iterate, but not by re-developing code, rather you can iterate through diagrams by refining the Domain Model. Changing a few diagrams is far easier (and cheaper) than changing working software.

In addition, if you are prototyping in parallel with DDD modeling then you can demo various prototypes (while stressing to stakeholders that “this is only a prototype.” )

Prototype from day one

Instead of starting coding working software from day one, we should start coding prototypes. This can be done in parallel with modeling. Prototyping differs from coding in that we are aware that this is throw-away code. We do not waste time testing the code and don’t develop details, we are “just playing” to see “how something will work”, we are getting familiar with the technology, with the “plumbing”. For example, we could experiment with how to create a React Form and send submitted data into a Pulsar Topic using Akka Streams. We want to investigate the mechanics of this concept so that when we start building the real thing we already have knowledge of it and have an infrastructure ready. Or maybe we just want to investigate whether this concept is appropriate for our implementation, after all, we may decide that it is not adequate for our project and choose another technology stack.

Reviewing the BDD specification.

Another good artifact for sprint review is the Behavior Driven Development specification as this is something that stakeholders can understand. DDD plays well with BDD, especially if you use the Domin Storytelling technique and diagrams. You can read my blog to see how you can use the output of a Domin Story diagram and use it as a Spock Testing Framework test specification.

I hope that in this blog I have raised your interest in DDD and shown that “Yes upfront design” is a useful approach because iterating and changing diagrams is cheaper than iterating and changing working software.

P.S.

And to finish on a happy note…

An actual monkeys experiment

In 2002, lecturers and students from the University of Plymouth MediaLab Arts course used a £2,000 grant from the Arts Council to study the literary output of real monkeys. They left a computer keyboard in the enclosure of six Celebes crested macaques in Paignton Zoo in Devon, England for a month.

Wikipedia

You can download the full text created by the monkeys from the Wikipedia page, see the “Actual monkeys” section. The text is titled NOTES TOWARDS THE COMPLETE WORKS OF SHAKESPEARE and includes pictures of authors, monkeys. (No, they did not produce the complete works of Shakespeare 😄)