In my last post on architecture, I touched on the need for design simplicity. Simplicity is one of the 12 agile principles:

Simplicity – the art of maximising the amount of work not done – is essential.

So it must be important. But how do we get there? Why, when simplicity is so essential, do we keep developing complexity?  Antoine de Saint-Exupére gives us a clue -

Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to take away.

When we do design, we tend to take an additive approach. We look at a problem and add features until we consider the problem solved. The problem is that we tend to get carried away and add way more features than we need. We look at the initial problem and in solving that one, we lump together a bunch of related problems and solve those as well. We also have a habit of solving a whole bunch of problems that aren't actually problems yet but might be one day, just in case.

Good design, great design, is the art of looking at a solution and paring it down the the base essentials - the minimum we need to solve the problem. Let's look at a few examples of great design. The first one has been around for a very, very long time.

About 3000 years ago, the bronze age inhabitants of what is now Uffington in England, laboriously carved a series of trenches into a local hillside and filled them with crushed white chalk. Those trenches were in the shape of a stylised horse. They wanted to draw a horse on the hill and with the primitive tools at their disposal, clearly couldn't make it realistic. What they drew though is distilled essence of horse. It's clearly a horse but take a single line away and it is no longer a horse. It is real minimalist design.

Why they did this, no one knows but the figure is so striking that it has been maintained to this day. To keep its shape, it needs re-cutting and chalking every 7 years. Every 7 years for over 3000 years. That's over 400 times the locals have looked up at the hill and said "that is worth preserving". If the mark of great design is longevity, then the Uffington horse is clearly great design.

2850-ish years later, an artist named Pablo Picasso did something very similar with a picture of a bull.

Starting with a realistic portrait, he systematically pares it down to the point where it can't be simplified any further without ceasing to be a bull, but at the same time it is clearly and unambiguously a bull.

What about this little gizmo?

Those of you who have used one are probably nodding your head in recognition of true design genius. Those who haven't are scratching your heads wondering what the heck it is. This little gem is a Tupperware orange peeler. It really deserves to be better known than it is. It is the perfect solution to peeling an orange. "What's wrong with a knife?" I hear you ask. Unless you are pretty good at peeling oranges, knives make a mess. They cut too deeply and let the juice escape or they cut too shallow and leave pith all over the orange which you have to laboriously peel off. The Tupperware peeler solves these problems. The hook cuts the skin to exactly the right depth without breaking the segments and getting juice everywhere and the flexible flat end levers off the cut skin and pith without being sharp enough to damage the segments. The perfect, minimal solution to the problem of peeling an orange.

OK, what about a tech example? Unfortunately, tech is where good design tends to be really hard to find. We tech people seem to have a built in, irresistible urge to complicate things. If it ain't broken, it doesn't have enough features yet. Back when I wrote code I used C. C is a lovely language. Simple, elegant, almost (but not quite) minimal. Using it, you could focus on solving problems. We then replaced C with C++, a language so baroque and complex that it's pre-compiler directives alone are Turing complete. Yes, you can write your entire solution as code that executes in the pre-compiler. We then added the Microsoft Foundation Classes on top of this complexity to make something so incredibly complicated that you now spent most of your time resolving weird MFC errors and much less time actually solving problems. And things just got more complex from there.

To be fair, tech design is different to drawing a minimalist bull. For a start, no one ever went to Picasso and said "Great, now make your bull run our payroll system as well as the thing we originally designed it for". Art does not need to be extensible. Tech often does. Minimalist design in tech is a real challenge. We have our innate need to complicate things, plus a very real need to extend things as needs change. Can it be done? Yes, but it takes effort and discipline.

Google have so far resisted the urge to complicate their home page with extra functionality. It still does one thing and does that one thing well - it lets you search for stuff on the internet. Compare that to the sites they were competing with back when they were new. Look at Yahoo's home page. Yes it has a search box but it also has about 50 other features. Look at...actually, when I think of all Google's competitors in search back in the day, Yahoo is the only one left and it just licenses Google's search for its search feature. That should tell you something about the power of doing one thing well.

The best example I can find of good design in software is Amazon. They made the call years ago that their architecture was going to be services. They re-engineered everything into services. Services that do one thing well with a clear, well defined interface so it's easy to use them.

Is their architecture simple? Not really, it's no Uffington horse, but then again, what they are doing is slightly more complex than a picture of a horse needs to be. The architecture is as simple as it can be while doing what the business needs, and importantly, it's made up of pieces that are also as simple as they can be with interfaces between them that are as simple as they can be. Each service is looked after by one team that knows it deeply and each service can be altered and improved internally as much as they like. As long as the interface is maintained, no one else gets impacted.

This didn't happen overnight. It took time, and lots of money. Remember what I said about decision and effort? The pay off though has been huge. Amazon was able to use its services to create a whole new business around cloud infrastructure. The services they wrote to make computing infrastructure in their vast data centers available internally could also be used to make the same infrastructure turn a profit by exposing it externally. Their simple architecture allowed them to be flexible and innovative.

Spotify did something similar with their platform as well (although they have not yet branched out into cloud infrastructure). Their modular architecture allows individual parts of the business to innovate without impacting others. If they had stuck with their original monolithic architecture, no matter how cleverly designed, their pace of change would have been much slower.

Simplicity allows flexibility. It allows innovation. It allows extension. If design is complex, it is hard to change. Build your system from simple pieces that communicate in well defined, simple ways. Design for flexibility so you can add features later rather than trying to design them in at the start. Who knows what opportunities will present themselves in future?

Resist the urge to add complexity and start embracing simplicity.