xDD: An Overview

I don’t know if it’s more comical or tragical to see all those xDD combinations that exist in software development. By “xDD” I mean any one of TDD, BDD, DDD, RDD, FDD, etcetera. Software developers often make fun of this our tendency to suffix everything with “DD”. I have three points to make about this:

  1. People get confused. They have a hard time understanding and keeping up with all the buzzwords that float around, especially if they are similar. There is some risk that they’ll simply discard all of them, even though some xDDs are truly invaluable techniques for a professional developer.
  2. Even if someone thinks that one of the xDDs would be useful she may, falsely, believe that the xDDs are mutually exclusive. Some of them are, some are not, some are in-between.
  3. This is a power-struggle, in some sense. The whole issue revolves around what should drive software development, i.e. what should be the most important thing. That’s a pretty big issue. What if you could go down in history as the person who understood software development so well that you found the magic key to unlock the whole field? Mind-boggling. (For the record, I don’t think there is one.)

This first post focuses on the first point; what these xDDs are. I have selected three of the most popular ones today, which I know pretty well, and tried to describe them concisely. I’ll also mention a few other xDDs as well.

Domain-Driven Design

DDD is an approach to designing software system based on the basic premise that the model you use to abstract the basic concepts and relations of your application, your “domain“, is really the most important part of any system. It’s what sets your application apart from all the others. This is where the real complexity of the problem lies and where the real gains can be made. Databases, app servers, GUI frameworks, and all that are really mere technical details, not essential to the problem. Therefore, the focus of our efforts should lie with the domain model.

DDD could be viewed as “thinking tools” or patters of software design. Some of them are on detailed level, e.g. types of relationships that exist between concepts. Others are on very high level, e.g. how different models relate to each other. Most of the time, DDD stays away from the “how”, although techniques like workshops with domain experts and iterative development are implied.

In DDD we work according to the Highlander principle: There can be only one (model). We use the same model when we talk to domain experts, when we draw diagrams, and when we code. Everything is not visible everywhere, because it’s not needed to communicate, but it’s there. This does not to imply that there is only one model in an organisation, or even a product. Models live in a bounded context.

Gradually, by working intensely with domain experts we gradually learn to understand each other and the correct terminology. These names are incorporated into the domain model and used very specifically in the model. This is called the ubiquitous language since it is used everywhere.

DDD is much more than this, e.g. suggested types of design building blocks and larger, strategic patterns. If you want to learn more, Eric Evans’ book is the reference.

Test-Driven Development/Design

TDD is an approach to designing software using executable tests. The basic rule is to never write production code without first creating a failing test. The implementation should be the simplest possible that we can live with. As soon as the test is working again we refactor our design to make it easier to understand and maintain, e.g. extracting small methods or renaming variables. After this, we move on to the next test and repeat the process until we are satisfied with the complete behaviour.

TDD done well focuses on designing a robust implementation of the behaviour we’re interested in – not achieving an all-encompassing test suite. TDD focuses mostly on one or a few classes at a time. Larger designs can be attacked, mostly by letting the tests lead us towards a flexible and testable design. It is believed that working, large designs grow (or “emerge”) from working, smaller designs.

There is a strain of TDD often called Acceptance TDD (ATDD) or Story-driven development, where you take TDD to its highest level; working with the customer. We define a requested feature (behaviour) using high-level, system tests, written in the language of the domain. This means you can drive out a slice of complete system behaviour from tests that the customer understands and co-wrote. That way, the customer becomes an active participant in the project.

There’s much more to TDD/ATDD, from tactics on how to pick your next test to how we handle system integration. If you want to learn more I recommend the book by Lasse Koskela as a starting point.

Behaviour-Driven Development

Finally, BDD is a variation and extension to TDD and ATDD, combined. A BDD development cycle starts with a story, written in collaboration with a customer. The story is broken down into scenarios (often called acceptance criteria), using a semi-structured form. These scenarios are then implemented as executable examples of the behaviour we’re after.

For each scenario, the developers drive the implementation of the requested behaviour, going fairly strictly from the outer layers of the application (the user interface, normally) all the way to its core. This is often called developing outside-in. To facilitate this, mocking techniques are used to great extent, since outer layers may depend on logic that should reside in inner layers but which has not been developed yet. This practice is advantageous since it removes all speculation and much rework from development.

BDD is very concerned about “getting the words right”, as Dan North has put it. This can only be achieved by collaborating with and observing domain experts at work. This collaboration results in the executable examples I mentioned above. In the ambition of calling things by their correct name, BDD has replaced a lot of the terminology from TDD. For example, in BDD we write “specs” or “examples” – not “tests”. We don’t care much for “units”, we’re targeting the “behaviour”. BDD is so much more, from creating robust mocks to Neuro-Linguistic Programming. There is no book strictly about BDD as of yet, but the Ruby book about RSpec, Cucumber and friends (just about to be released) by David Chelimsky et al, embodies its ideals perfectly.

Other xDDs

Responsibility-Driven Design

Responsibility-Driven Design (RDD), invented in 1990, is a way of thinking about and designing object-oriented software, focusing on roles and responsibilities instead of data and algorithms. The system is fulfilled by a collaboration between a collection of stereotyped objects. I would say that RDD is in the same class as the more recent DDD.

Feature-Driven Development

Feature Driven Development (FDD) is an iterative and incremental process for developing software (one of the agile processes). It includes several engineering practices, e.g. domain object modelling. FDD is a different beast from DDD and TDD/BDD, which are not development processes.

Documentation-Driven Development

Documentation-Driven Development can mean one of two things: 1. (derogatory) Using extensive and bloated documentation procedures to develop software in an wasteful manner, where the documents grow more important than the software you should deliver, and 2. Developing software by starting with one of the end results, its documentation. Of course, since there are many different kinds of documentation there are a number of interpretations of this idea. One of them is UGDD (see below).

User Guide-Driven Development

User Guide-Driven Development (UGDD) is a form of Documentation-Driven Development. It is based on the old idea that to develop useful software you should understand the user and their needs. One really good way to do that is to write the user guide first, perhaps in collaboration with some typical users. To do this iteratively and incrementally, of course, you would write only a small part of the user guide first and refactor it along the way. This is a nice idea which is not very far from the story-driven development in BDD.

Defect-Driven Design/Development

They say that the best jokes are the ones that contain a core of truth inside. This is a joke, but the idea is really not bad when you consider it. Watch this movie of a tipsy (or at least, veeery tired) Kirk Pepperdine for a description and a good laugh (from Jfokus 2010).

5 thoughts on “xDD: An Overview

  1. Tired but strangely enough the next bar we hit on declared me too tipsy to get into!

    I really don’t see what the problem is. D cubed is very agile. 😉


  2. And don’t forget the old TODO-Driven Development:
    http://secretgeek.net/TODO_driv_dev.asp 🙂

    But seriously, even though I can understand your issues with all the xDD’s, I think that we need to trust people with the choices and hope that they find what’s right for them. Experimentation with different approaches is what moves us forward (and sometimes backward). A bit more fantasy regarding the names of newborn approaches would be nice but as Shakespeare wrote:
    “What’s in a name? that which we call a rose
    By any other name would smell as sweet;”



    • Hi Morgan!

      Thanks for your input. I just wanted to clarify things for newcomers in the game. But…

      I think that what we call things (names) are really important, Shakespearean or not. The quote you give is taken a bit out of context. If I’m not totally mistaken the quote is from where the lover (Romeo) tries to justify that the target of his affections belongs to the “wrong” family. This has nothing to do if words are important or not. What do you think Shakespeare himself would have said on this matter? Do you think he felt that names were not important?

  3. Hi again,
    regarding the Shakespeare quote; you’re absolutely right about the context, but for his metaphor to be relevant the statement needs to be considered true for the vehicle. So I think that he actually meant that the qualities of the rose (or xDD) would stay constant regardless of its name (not saying that names are unimportant).

    I do think that names are important since they provide first impressions and “first impressions last”. But, I also think that it’s my responsibility as a beholder/reader/listener to not judge the book by its cover and to look at what’s behind the name. How I, as a sender of information, choose to name my method is of course very important for my chances of success when it comes to spreading the word but as a receiver of the information I don’t feel that I can blame anything on a bad name. I can’t expect the name to convey everything (or anything) about the subject, it’s to a large extent only a placeholder.

    That said, I’d like to thank you for great articles on your blog. I may not agree with every single line but you often provoke new thoughts.



Comments are closed.