February 24, 2006

...Learn TDD with Codemanship

Innovation & The Problem Tree

A model of the process of innovation, and therefore of software projects, that is serving me well at the moment is that of a Problem Tree. Think of the problem of transmitting an image of the surface of Mars electronically back to Earth. It's a big technical problem that space scientists and engineers had to solve way back in the 1960's using antiquated technology - well, antiquated by today's standards.

The problem can be broken down into sub-problems (to use another made-up word). First of all: how do you capture an image of the surface of Mars so it can be transmitted electronically? How do you transmit an image electronically? How do you receive an image that has been transmitted electronically? How do you display an image that has been transmitted electronically? How do you make an electronically transmitted image available for reproduction in books and magazines? And so on...

Each of these sub-problems can again be broken down into smaller problems that need to be solved. The process of innovation and problem solving can be thought of as a walk down the Problem Tree. In previous posts I've also referred to this process as an evolutionary walk through solution space, so my thoughts now turn to how I can tie these two models together - since we might naturally expect them to be opposite sides of the same coin. (If a solution is to a problem what a statistic is to a probability.)

Again, my thoughts turn to probability and dice games. In an Agile project, each of these problems might be written on story cards (visit Rachel Davies' web site for an intro to Agile Requirements). If we don't know how to solve the problem off the bat, we might break the story card down into smaller stories, or engineering tasks. We might break some of those tasks down even further before we start the meat-and-potatoes work of development. When we develop, we walk further down the Problem Tree. We might break a usage scenario down with a sequence diagram. We might write a unit test for one of the interactions. We might need to solve several small problems to pass that unit test. We might even leave placeholders (like Mock Objects) for branches of the tree we plan to explore later.

Every step we take in this walk down the Problem Tree (and through solution space) is inherently unpredictable. We don't know how long it will take to solve a problem, and so every step we take can be thought of as one or more throws of the dice. Some steps will be easier - that is, more probable - than others, and will, on average, take less throws of the dice.

The estimates that developers write on story cards are in effect measures of how improbable it might be to find a solution. The more improbable, the higher the estimate of relative difficulty or effort. As a rule, bigger Problem Trees tend to have greater improbability. If you think about it, this makes some sense. The probability of finding a solution to the problem of sending an image electronically from Mars will be a product of the probabilities of all the sub-problems that make up its Problem Tree. The more branches in the tree, the more improbable a solution to the root problem is likely to be.

In the near future, I will be looking at how this model ties in with the evolutionary solution space model of innovation, as well as exploring why some strategies for innovation might work better than others.
Posted 14 years, 11 months ago on February 24, 2006