The problem with solutions

First date. You’re out for dinner and the meal has gone well. Good food, great conversation. The waiter brings the bill, and you ask to pay with your credit card:

May I submit my billing info to your merchant account via your payment gateway?

Your date looks at you askance: nobody talks like that. Do they?

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:

Solutions vs Problems

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.

Published by Matt

I write software, and love learning how to do it even better.

Join the Conversation

3 Comments

  1. +1 Matt,

    Very much in line with Lisa Crispin (et.al) Agile Quadrants – are your tests Business Facing or Techonology facing?

    Still your setting it up as languages in two domains illustrates the point very well. Business facing tests are best described in business language – in the source code even, if possible.

    As a bloke with a problem (I want a scarf) I’m not as such interested in the details of seams and fabric.

  2. 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. 🙂

  3. 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.

Leave a comment

Your email address will not be published. Required fields are marked *