In any software project, there are two main domains: the problem domain and the solution domain. The problem domain is where your customers live. The programmers and other technicians working on solving that problem operate in the solution domain.

Both of those domains contain funny terminology, a dialect of English you can only learn by spending time amongst the people who speak it. This helps you to figure out which domain you’re in by listening to the language being used.

Here are some examples:

This specialised terminology is inevitable. Both business people and technicians need to use specialist language to communicate effectively with their peers. But what about when those two tribes need to speak to each other?

David West’s Object Thinking eloquently describes the natural divide between these two domains, and the problems it causes. In his view, our job as programmers is to build a model of the problem, and allow a solution to naturally fall out of that model. As soon as we start thinking in solutions, we lose sight of the problem and create ugly solutions. This implies that, as programmers, we need to immerse ourselves in the problem domain.

Using executable acceptance tests written in plain language helps you to keep your language and thinking rooted in the problem domain. This is why I have such an objection to Cucumber scenarios that talk about clicking buttons and filling in fields: they’re jumping into the solution domain too early.

Instead, I like to use Cucumber features as the place where we document our understanding of the problem domain. Writing those features collaboratively with people from both domains helps us to grow that understanding, and increase the overlap between the two domains.

Posted by Matt on Thursday, January 17th, 2013, at 3:49 pm, and filed under BDD.

The magic question: how do I encourage prospective clients to approach me with questions, rather than with requests for a solution that they think I provide? Of course, I mean this well outside the context of BDD.

But Jesper, why do you know that you want a scarf? Isn’t that already a solution to a problem?

I find it thoroughly natural to seek implementations of solutions; I’m glad that I’ve learned how to reverse-engineer/rediscover/re-highlight the underlying problem. I’m also glad that I’ve learned how to help other people do the same.

Post a Comment

Your email is never published nor shared. Required fields are marked *