Always Start Simple

Humans are amazing at building complex things. We build robots that explore other worlds. We create transit systems that move millions of people safely every day. We design machines that can filter and sort the whole of human knowledge. We collaborate to make amazing drama and music. Humans create systems vastly more complex than any other creature.

Humans are terrible at building complex things. We have a track-record of failed projects as long as the history of engineering. The Tacoma Narrows Bridge disaster, the loss of the Space Shuttles Challenger and Columbia, the Chernobyl catastrophe, and the current state of Internet security.

How can both these things be true? What’s the difference between successful and failed complex systems? How can we increase our chance of success when we’re working with complexity?

The key insight is this: Every successful complex system evolved from a successful simple system. There are no exceptions.

That’s how to build a successful complex system. Start by building a simple system. Make the simple system successful. Ensure that you understand it completely. Then iterate to add more capability, making sure that the whole system is still understood. This won’t prevent you from making mistakes. You’ll add things that create instability, or break other bits, or just don’t work. But if you trust the core system, it’s at least possible to go back to an understood position and try again.

If you try to build a complex system from scratch, you will never completely understand it. When things inevitably go wrong, you won’t have a well-defined, dependable core to return to. It will be enormously difficult to work out what the root cause of the problem is, and you will never have confidence that you are really fixing the issue. You will never reach the successful complex system that you aimed for.

Brian Kernighan, one of the founders of modern software engineering once observed “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” The same applies to any complex system. If you build something at the outer reaches of your ability, you will not be able to fix it when it goes wrong.

If we look at successful complex systems, they can all trace their heritage back to successful simple systems.

Modern telecoms networks evolved from human-switched electrical circuits, through electro-mechanical exchanges, to digital circuit switching, to packet-switching, to today’s amazing systems that give you gigabits of bandwidth in your handheld device.

Our incredible food logistics networks that let you eat California peaches in Brisbane winters, and New Zealand lamb in England (for a certain carbon cost…) can trace their heritage to weekly small-town markets.

The astonishing trust networks that facilitate our global financial systems evolved from bookkeeping systems that emerged in renaissance Italy, coupled with communication networks that emerged to finance travelling armies in the middle ages.

Every successful complex system emerged from a successful simple system. There are no exceptions.

I led a team that built a system for modelling telecoms networks. We needed to migrate from our OS-native interface to a web-based system because, frankly, it was 2006. Our launch customer for the interface had a brand-new digital backbone network. We were all experienced software people, so we wanted to start with a simple use case. Perhaps a mesh of a few routers with 100Mb and 1Gb links over Ethernet and ATM Fiber for the first version, the team thought. Maybe four link types and four device types. 

The oldest, wisest member of the team put her foot down. “No, that’s way too complex. Our first version will have one link and two identical devices. And they won’t be routers. Iteration one is ‘Two Tin Cans and a Piece of String’.”

We were not thrilled by this approach. “That’s far to easy. It won’t prove anything. We’ll have it done this afternoon, then what do we do?”

The Wise One replied “Then we’ll do Version 2. But first, we’ll do the simplest thing possible. If it’s so trivial, we’ll be done today, and we can do the next thing.”

We didn’t have it done that day. We didn’t have it done that week. We ran into platform issues, and library bugs, and found out one of our foundational assumptions was badly wrong, and the initial performance was terrible, and we couldn’t make it work on Internet Explorer (It was 2006), and all sorts of things went wrong. But we never blamed the complexity of the model or had to abandon things we didn’t need. It took us four weeks to get to ‘Two Tin Cans and a Piece of String.’ It took another four weeks to add everything we needed to model the whole of our customer’s network, and at every step we trusted the foundation we were building on.

Because we started by ‘Building the Simplest Version Possible’ – the version nobody could possibly use – we ended up with a simple, robust platform that supported our next set of features. That structure then supported the next set, and so on. Of course, we ended up adding features that broke things, or layering it too fast and having to pare back to the solid layers, but by having an ever-growing core that we could trust, we were able to build a truly sophisticated and complex system that was dependable.

When you are tasked with creating a complex thing, whether it’s a new product or process or organisation or anything, the first step is to identify the simplest thing that could possibly work. It doesn’t have to solve the whole problem. It doesn’t have to be ready for a customer. It certainly doesn’t have to be pretty. But it must be simple. Once you have the simple thing, the next step is to make it successful. Identify a part of the problem that can be solved with your simple system. Focus on that. Once you have a successful simple system you can start to iterate.

People will challenge you. They want their feature *now*. “Can’t we just have this one thing to make it more useful?” The correct answer is not ‘yes’ or ‘no,’ It’s “later.’ They will argue that the simplest system will make it more expensive to add complexity later. Yes, but it will be possible. With a complex foundation you will probably never get to add the features you need later.

Until you have a successful simple system, you can’t have a complex system. It’s far easier to understand and fix a broken, simple system than it is to fix a complex system that may be beyond understanding. Fixing the complex system may very well be impossible.

By building the simplest possible version first, you move away from speculation about what should happen towards knowledge of what will happen. The earlier that you create that knowledge, the sooner you will deliver something that solves a real problem. From there you can iterate towards complexity, with confidence that you are building on rock, not shifting sands.

Build the simplest possible successful thing. Then iterate. That’s how we create successful complex systems.

Charles Randles has over 20 years experience helping businesses unlock their full potential with Business Agility. Find out how we can work together to turbocharge your business execution.