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:
- 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.
- 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.
- 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.
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.
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.
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.
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 (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 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.
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).