What is as simple as possible?

One of the most celebrated principles of our time is the concept of simplicity. But how do you obtain simplicity, and when do you know a solution the simplest possible?

Einstein is famously been quoted to have said "A solution to a problem should be as simple as possible, but no simpler". In the same lines Leonardo da Vinci is reported to have said "Simplicity is the ultimate sophistication."


Great! I can hear what you are saying, but what does that mean?

How do you obtain simplicity? On this question - ideas have been widespread.

A good source to understand what we are looking for are The Laws of Simplicity . A set of 10 laws that partially describe how to obtain simplicity, partially describe how you can perceive simplicity and partially state that some things cannot be made simple. A good reference for reflection, but from my point of view - not simple enough!

The site The Simplicist describes two approahes to achieve simplicity (1) Simplicity by Reduction and (2) Simplicity of design. The titles are rather self explaining, but read the source to see the descriptions. This site is really simple so they are living up to their ideal, but is it maybe too simple? Anyhow, the two approaches may come in handy, so lets keep them in mind.


When is a solution the simplest possible? This is the hard question. I use a three step solution to this. Might work for you as well?

1. I believe you must base it on the possible known solutions to a problem. There will be solutions out there that may be found in the future, but simplest possible does not include the unknown by definition (the unknown is not possible at this point in time...).

Ex: Example could be that in 1850, the simplest solution to communicate a short message between Australia and England could be to send a postal mail by ocean traffic. Today it might be to send an SMS or just make a phone call?

2. Select the solution that based on key metrics (ie production time, money, energy needed) that you believe give the lowest value given lowest accepted value for some quality metrics/tests (ie defects, pollution, service calls etc ). This is based on the simplicity be design principle (2) above.

Ex: Our message could be sent by email instead of SMS, but would that be fast enough based on our expected response time from our receiver? We could also call instead to get the message over instead of sending and SMS, but would that be acceptable to the receiver. Would it be simple for him/her and take the little time it needed?

3. Once you select your solution, remove the least necessary part. Ask yourself will it still work given the quality metric/test. If the quality metric/test is still evaluated acceptable: Repeat and see if you can remove one more layer. This is based on the simplicity be reduction principle (1) above.

Ex: Say in our SMS communication. Can we remove the need to send multiple SMSs. Is it acceptable to only send one SMS with the message and require only one response? Maybe in some cases you can remove the response itself by saying that "if OK, no need for response. " That would assume that you really trust that the message was received (!), but still it proves the point of multiple possible reductions.

Try it! It works pretty well for me, and you get something that is pretty close to As simple as possible, but no simpler.

The Pareto Principle - After 101 Years

The Pareto Principle or the 80/20 [1] rule as it has often been called, was first noted in 1906 by economist Wilfredo Pareto while he was studying the wealth distributions of people. Apparently, 80% of a nations wealth was in the early 1900s controlled by 20% of the population. Since then, the Principle has been popularized in management theory and is applied in all sorts of domains. Take for instance blog entries such as this [3].

It seems that 100 years later the relationship has become even more differentiated. According to [2] 10% of the worlds population control 85% of the wealth. Hence, if Pareto had lived today, the Pareto principle would have been called the 85/10 rule.

[1] Pareto Principle - an explanation of the Pareto principle and further reads.

[2] UN study of the wealth distribution in the world - ppt of some very interesting figures.

[3] Notes to Self blog entry about 80/20 in your daily life

The Balanced Simplicity in a Classical Music Recording

The goal of a classical recording is of course to create a sound in a stereo that gives the listener the impression that he is sitting in that concert hall. The process goes though several steps, the major ones being recording, editing and mastering. I was talking to a Classical Music Master yesterday, and among other things he explained the ultimate recording setup: 2 microphones!

Apparently, one studio uses one microphone in each seat in a concert hall to make the recording and the result is terrible. The sound arrives in each seat at different times and in that way it becomes distorted. Furthermore, the mastering becomes really complicated due to all the channels the Music Master needs to work with. By having two microphones, you receive

Occam's Razor strikes again: "A solution to a problem should be as simple as possible, but no simpler." In the mastering process, the master reworks the analog recording to a digital piece. This is apparently a balanced analytical process and intuitive art. The master looks at the musical digital profile and listens to the sounds for impressions in an iterative manner. The master also needs to take into account that most listeners are using simple stereos that do not bring out the full quality of the music. So to summarize, a digital musical masterpiece is a product of fine balance of simple building blocks.

Being Orthogonal and DRY through McKinsey's MECE

Two of the important lessons that many software engineers have learned through experience is so brilliantly explained in the book Pragmatic Programmer:

• Orthogonality - "Things that are not related conceptually should not be related in the system."
• DRY (Don't Repeat Yourself) - "Every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."

While skimming through the book The McKinsey Mind (a follow up of another very similar book called the McKinsey Way) I suddenly found the same principle being present in the Firm's analysis methodology. The principle is called MECE and stands for:

• (ME) Mutually Exclusive - "must ensure that a list of items is mutually exclusive, or that every item is separate and distinct"
  
• (CE) Collectively Exhaustive - "it must also be collectively exhaustive, that it includes every issue relevant to the problem"
  

According to the source, the MECE principle is used by the associates in the Firm to analyse different scenarios or to develop a list of questions concerning a particular issue. It is funny to see that the same principle is applied by both successful software designers and successful business analysts. The principles are just coined differently. DRY and orthogonality covers ME. You can say that CE is supported by any working software system in that it works.