The most innovative solution is sometimes the simplest

“That’s it?”

I rather like that reaction.

A team may have spent several weeks understanding a problem, testing different avenues, measuring, building prototypes, questioning some of its assumptions and gradually eliminating solutions.

Then one day, something works.

And sometimes the final solution looks almost obvious.

“That’s it?”

Yes.

But perhaps it took travelling through all that complexity to understand that, in the end, it wasn’t needed.

In R&D, we sometimes have a strange relationship with complexity. A sophisticated solution naturally feels more innovative. More components, more algorithms, more abstraction or a newer technology easily give the impression that more engineering has been done.

Yet the complexity of a solution says nothing about the difficulty of the problem that led to it.

And even less about its quality.

Simple doesn’t mean simplistic #

There is an important difference between simplifying a problem and ignoring it.

A simplistic solution sets aside part of the constraints to reach an easy answer.

A simple solution, on the contrary, can be the result of understanding the problem deeply enough to know exactly what is necessary — and, above all, what is not.

That is quite different.

If I remove a mechanism essential to the safety, performance or robustness of a product, I haven’t simplified the system. I have merely moved the problem.

But if two architectures meet the same constraints, and one needs three components where the other needs twelve, the second isn’t automatically more innovative because it is more sophisticated.

It is simply more complex.

And that complexity will need a reason to exist.

Complexity has to buy something #

Every additional technical layer has a cost.

It will have to be developed, tested, documented, maintained and understood.

It will potentially introduce new dependencies, new failure modes and new interactions with the rest of the system.

This obviously doesn’t mean complexity should be avoided.

Some problems are complex and require complex solutions.

But when I add some, I like to know what it buys me.

Better performance?

More robustness?

A new capability?

Reduced risk?

Better maintainability?

A large enough saving of time?

If I can’t answer, it may be worth asking why that complexity is there.

Technology can easily become the goal #

This is especially visible when certain technologies become very attractive.

Today, that is obviously the case with artificial intelligence.

A problem could be solved by a relatively simple deterministic algorithm, but using an AI model sometimes looks more innovative.

So we add a model.

Then we have to handle the data, the inference, the performance, the edge cases, the monitoring and everything that now comes with that decision.

All of this can be perfectly justified if the AI brings something we wouldn’t have obtained otherwise.

But if it merely delivers, with more complexity, the same result as a simpler solution, where is the innovation really?

And AI is only one example.

We can do exactly the same with a distributed architecture, microservices, the cloud, a new framework, a more sophisticated sensor or any technology attractive enough to become a solution before the problem has even been stated properly.

Sometimes innovation means removing #

We easily picture innovation as an addition.

Adding a feature.

Adding a sensor.

Adding an algorithm.

Adding a software layer.

Adding a new technology.

Yet an important part of engineering work sometimes consists of doing exactly the opposite.

Removing a component that has become useless.

Deleting an abstraction that no longer brings anything.

Replacing several mechanisms with a single one.

Dropping a feature no one really needs.

Reducing the number of possible states of a system.

Or simply accepting that a problem can be solved with something we already know.

The value created is then not in what we added.

It is in what we understood well enough to be able to remove.

An obvious solution can have taken enormous work #

This is probably what makes some innovations hard to value.

When the result is simple, all the work that led to it disappears.

We no longer see the abandoned prototypes.

The measurements that invalidated a hypothesis.

The architectures that looked promising.

The weeks spent understanding why something wasn’t working.

We only see the final result.

And when it looks obvious, it is easy to think it was obvious from the start.

It usually wasn’t.

It is even, at times, one of the signs of successful engineering: the complexity needed to understand the problem is no longer visible in the solution that results from it.

I’m not looking for the simplest solution #

We should nonetheless beware of the opposite excess.

Simplicity must not become a dogma.

I don’t systematically look for the simplest solution.

I look instead for the least complex solution capable of properly satisfying the need, its constraints and the acceptable level of risk.

Sometimes it will be extremely simple.

Sometimes it will require a complex architecture, several disciplines, sophisticated algorithms or years of R&D.

In that case, the complexity is legitimate.

The work then consists of mastering it and, whenever possible, of not passing it on to whoever will use the product.

A user shouldn’t have to bear all the complexity that was needed to solve their problem.

“Why had no one done it this simply before?” #

We often associate innovation with one reaction:

“How did they manage to build something so complex?”

But there is another that I find at least as interesting:

“But why had no one done it this simply before?”

Behind that apparent obviousness sometimes lies an enormous amount of understanding, trial, error and decisions.

Innovation, then, isn’t necessarily the amount of technology we manage to put into a product.

It can also be the amount of technology we manage to keep out of it.

And that is probably a fairly good way of explaining what I mean when I write:

Complexity → Clarity.