October 13, 2015

...Learn TDD with Codemanship

Widening The Goalposts By Asking "Why?"

It's been probably a decade or so since I last visited this topic, but it comes up often in conversation, so I thought this would be a good time to revisit it.

One of the key reasons why it's so important for software teams to have high-level goals to work towards is because high-level goals tend to leave us wider potential solution spaces for meeting those goals.

One of the biggest problems in software development is our tendency to confuse problems with solutions. That is - put more bluntly - we tend to be working towards implementing someone's design rather than solving a problem.

User stories, for example, are typically design decisions: descriptions of features or properties the software must have. These are not requirements, they are solutions masquerading as requirements.

I can illustrate why this is a problem with a very simple programming language I've just invented called DICE.

In DICE, we can specify the results of throws of a pair of dice, like this:

{ 1, 6 }

Imagine our customer writes user stories along the lines of:

As a gambler, I need to throw a 1 and a 6, so that I can score a 7.

As a developer, I would seriously consider tearing up the first part of this user story. Why does it need to be a {1, 6} ? What the customer wants is a total of 7.

There is only one way of throwing {1,6}, but there are 6 ways of throwing a total of 7.

The number of different ways of throwing something is the solution space. Throwing any combination that totals 7 has six times as many solutions as throwing specifically {1,6}.

{1,6} is a design for scoring a 7. But 7 is the requirement. By taking a step back from the design and asking "why do they want to throw {1,6} ?", we can discover the real goal and widen our choices for achieving it.

When we have more choices, our odds of finding a solution with limited time and resources increase. It's the most powerful question a team under time pressure can ask: why?

Many are the times when my team's been banging up against it time-wise and we've taken a step back, gone back to the real underlying goal, and come up with a simpler and quicker way of giving the customer what they really want.

And we don't have to stop at one "why?"; so the customer really wants a total of 7. Again, why? The customer tell us "because I win if I throw 7 or 11".

Aha! So our solution space is even wider than we thought. Six ways of throwing 7, plus two ways of throwing 11.

And so on.

In the casino of software development, anything we can do to improve our odds is likely to be a good thing. Widening the solution space - by raising the level of the requirements above designs - can be a powerful aid in this.

Posted 2 years, 1 month ago on October 13, 2015