Simple but hard

Matthew Bellringer
Meaningbit
Published in
4 min readAug 20, 2017

Some problems are really easy to describe, but difficult to solve. They are simple but hard.

Millau Viaduct, France. Photo by Tony Hisgett — https://www.flickr.com/photos/hisgett/

The Millau viaduct is a stunning piece of engineering. It has clean, simple lines and it does nothing more sophisticated than provide a road bridge so traffic doesn’t have to wind it’s way into a valley and back out again. However, building it was not easy. It took three years, €394m, and cutting-edge construction techniques to make. It is a classic solution to a simple but hard problem.

Engineering approaches excel at solving these kind of problems. They start with a nice, neatly defined problem space. In the case of the Viaduct, it’s getting cars from one side of the valley to the other. It’s the kind of problem whose essence you can capture in a sentence or two. Having a nice clear goal means measuring success is pretty straightforward. Does the viaduct carry cars across the valley without them plunging off into the abyss at regular intervals? Good, it works.

It’s a little tougher to identify what makes this kind of problem hard. At its root, it’s because no-one has solved such a problem previously. Perhaps that’s because no-one has made anything that big before, or that fast. Perhaps no-one has needed this kind of product to survive deep in the ocean, or at the edges of space.

Coming up with a genuinely elegant solution to a simple but hard problem requires either the development of new techniques, the combination of existing techniques in new ways, or both. It requires innovation and creativity.

The problem with simple but hard

Even in the realm of physical engineering, there are difficulties to simple but hard problems which go beyond solving the problem itself. The first of these is in the way people relate to and understand such problems.

Because simple but hard problems are, by their nature, easy to describe, people often assume that they have a trivial solution. Worse, when presented with an genuinely elegant, innovative answer to the problem, they can’t understand what was hard about coming up with that in the first place. This happens when people can’t effectively put themselves back in the position which they were before they knew what they know now. It’s a special case of the curse of knowledge, between current and past self. I can be a major risk factor when dealing with senior stakeholders and can significantly affect how seriously a project is taken.

The second problem comes from problems which are mostly simple but hard. Few neatly defined problems exist outside of thought experiments. The real world is messy. You can test for a lot of cases you expect to encounter, but you can’t test for all of them. You also can’t test for interaction effects, where one element starts affecting another in unexpected ways.

There’s another bridge, the Millennium Bridge in London, which suffered from just such an issue. When it was first opened, people reported alarming levels of wobbling as they were crossing the Thames. Small vibrations were amplified by the multiple footfalls of many people, and in response, people started to sway at a similar frequency, making the vibration worse. In the end, mass dampers had to be added to prevent the wobble.

Simple but hard problems in IT

You might be asking yourself what building bridges has got to do with IT projects. The assumptions which underpin many major IT projects are that the problems they seek solutions for are simple but hard. This informs project management practice, much of which is borrowed from manufacturing. It informs the way people tackle problems, and the expectations of users.

There was a time when such metaphors were relatively safe. IT projects would start with a clearly defined goal in mind, and would deliver applications to a specified number of trained users, who’d use the application in a specific way, to perform a set number of tasks. The application would work by itself, generating its own data.

Doesn’t sound much like anything you’ve worked on recently? Me neither. The levels of complexity inherent to any meaningful IT project pushes it well beyond the bounds of simple but hard. As the complexity of the problems increases the standard approaches to tacking them can, much like the Millennium Bridge, start to look a little wobbly.

We need to radically rethink our approach to how we understand these projects, and move beyond approaches inherited from physical engineering and manufacturing. The problems we face now are complex, and are a completely different beast. I will be writing a post about complex problems and how to work on them soon.

--

--