or What they mean with thinking outside of the box.

Reading this article reminded me of a concept that applies to software design, user interface design, hardware engineering, and pretty much to any situation where you have to solve a problem creatively. I have applied it in a number of disciplines, however I have not used it in my current software design work as much as I should.

It is the concept of designing breadth first, before developing an idea further by going deep. Most creative people I have met (including myself) have the natural tendency to go deep first. They are confronted with a problem, they immediately come up with an idea for how to solve it, they get to work developing that idea, and get stuck in one limited way of thinking.

Designing breadth first means you have to resist the urge to jump on the first solution that comes to your mind. When I got my degree in Mechatronics engineering, we learned how to design all kinds of cool stuff: robots, Human-Computer-Interfaces, weird sensors, vehicles, … The main objective during all these design exercises was to knock out of us the approach to jump on the first idea. It was painful and hard, however an invaluable skill to have. The final solutions were better than what we would have accomplished had we limited our development efforts to the path laid out by the first idea we had.

So what does the “breadth first” approach look like? In Mechatronics Engineering it meant documenting all solution approaches we could come up with before developing any one of them further. We called it a morphological analysis – a big word for a solution matrix. Once we had a number of very diverse solutions, we would go deep on as many as we could afford to. Going deep means fleshing out and developing further an idea until we have a solution implemented. In engineering that meant: finding materials, modeling in 3D, building prototypes, doing testing, preparing mass production.

Lateral thinking

Edward de Bono talks about this concept in his book “Lateral thinking”. In the book he contrasts lateral thinking (going broad, making jumps) with vertical thinking (going deep, sequential). He says both are necessary and complement each other very well. You start with lateral thinking, and then go vertical in the next step. He describes exercises that help you go broad first. Really good stuff. He has one quote that summarizes it quite well:

Vertical thinking develops the ideas generated by lateral thinking. You cannot dig a hole in a different place by digging the same hole deeper. Vertical thinking is used to dig the same hole deeper. Lateral thinking is used to dig a hole in a different place. (E. de Bono, Lateral Thinking, page 12)

My visualization

Here is an illustration that visualizes the concept: When you first start a project, you sit on the surface of the problem space and have to dig deep into unknown terrain in order to develop a viable solution. You have certain minimum expectations for what that solution should look like (green horizontal line).

Depth first

Most projects I know pick a spot on the surface and start drilling deeper until they cross the green line – hopefully within budget. You see how the project makes small adjustments in direction, however every new step is connected sequentially to the previous one. Eventually the project crosses the green line – even though I know of enough projects who never cross the line of being a sufficient solution.

Breadth first {.clear}

You sit on that same surface, are faced with the same problem as above. What do you do? You drill in as many places as you can and see what you find. The advantage is that you won’t get stuck in a local minimum. You might find an approach that is far superior to your expectations. An approach where you can go further than anybody would have imagined:

Go breadth first in software design {.clear}

I am not sure how often this approach is being used in software design. I haven’t seen much evidence. What would it look like? I do a lot of object oriented work and it could mean to slice my classes differently. I would draft one class structure, and then challenge all my assumptions about the problem space to draw another class structure, and another one. Then I would ditch object oriented programming all together. The point here is to shake things up. Here are a number of places to start:

• get inspired by some random pictures on flickr
• find Red Flag Words and challenge them
• challenge your industry’s common assumptions: Seaside is called the heretic web framework because it puts common assumptions in the web industry upside down: It shares everything where everybody else goes by the “share nothing” mantra.
• do some push ups or take a shower

What approaches do you use to shake things up?