Why divergent thinking leads to better software 💎

When handed a problem to solve, do you allow yourself to explore different solutions? Or do you just implement whatever first pops into your head?¹

I once spent a lot of time writing a system to import data in batches. Unfortunately, I didn’t spend much time on error handling and just did what felt intuitive. That caused me to design the error handling to fail fast, and abort whenever it found an invalid record. So a million-record batch would be stopped just because a single record was invalid.

Another time I wrote a logging system that wrote log records to an SQL database. Later I realized that this made it very hard to troubleshoot database connection issues. 😛

In both of these scenarios, I would have been better off if I had stopped and considered alternative solutions before investing time and effort in the wrong direction.

Divergent and convergent thinking #

Here’s where something called divergent and convergent thinking can help us.

Divergent thinking is a thought process aimed at generating many possible solutions, even messy or unconventional ones. Convergent thinking is about narrowing down to the best option using logic and evidence.

To use divergent thinking, you want to immerse yourself in the problem space, and explore many possible solutions in a short amount of time. Absorb not just facts, but meaning and context. Be inspired by other solutions, even in different fields. Allow your thoughts to become messy or even overwhelming. Only then can you simplify and act effectively.

The combination of divergent and convergent thinking is a powerful tool to first identify options, and then narrow down to find the best. It can be thought of as a diamond shape, which first becomes wider and then narrower.

The Double Diamond #

I’m not the first to think of this kind of thinking as a diamond shape.

The Double Diamond, developed by the British Design Council, is a visual representation of the steps taken in a design and innovation project.

As its name suggests, it includes not only one, but two diamonds.

• The first diamond represents the discovery process of defining the problem. All too often, we assume we already understand the problem—but for any non-trivial problem, that is unlikely.
• The second diamond represents exploring possible solutions, then narrowing down and delivering a single chosen one. In this process, we can build throw-away POCs, run A/B tests, and rely on the power of starting over.

For instance, when designing an API, you might first explore different ways users interact with data (discovery/definition), then prototype different endpoints or authentication models (develop/deliver).

While this model may be overly simplistic, it is valuable as a reminder to look up and broaden one’s perspective. In practice, we often iterate on problems, so we will effectively loop through multiple mini-diamonds. The model also reminds us to clarify what problem to solve, not just to find a good solution for the assumed problem.

If I had applied this approach, my batch importer and logging system would have turned out much better.

Next time, let yourself diverge before converging. It’s worth it.