Simplicity

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

There is a lot of great quotes about simple and simplicity but I am going to focus on this agile principles statement.

Why this one?

Because that is probably the quote people think of and consider least often in their search for simplicity.

Why do people strive for simplicity?

Because life is complicated, I could probably argue it is chaotic, but business systems luckily rarely are 🙂 Understanding complicated, mapping it out, dealing with it often gives you a headache so would it not be great if we could create a simple world? One where there are simple rules, everything nicely falls in place and delivering great solutions is like putting things together using Lego-like bricks that you can always somehow connect to each other. This image of simplicity has got nothing to do with the principle I brought up at the start. Very often that ends up being exactly the opposite where huge effort is put into creating this fake, simple world. Remember my shortcut post? This is another type of a shortcut people want to take – manage complications out of their lives – but they never succeed quickly realising this path is not a shortcut after all. First things that go in that case? All the rules that were meant to govern the simple world, they kill the simple world by 1000 cuts of exceptions and justifications for handling this or something else differently. All the promises of reuse and clearly defined components die with it.

What’s the solution then?

I believe that we should embrace complicated nature of our business environments and focus on not letting them slide into chaos. So what work can we not do then:

• Do: Compartmentalise complicated areas to keep other parts of the system simple. Focus on simple definitions of in and out of components and deal with complications in a way that’s not visible to an external user. Not done: development of complex components all over the system and additional components even more complicated ones that transmit, store and translate complexity
• Do: Always start with “Can I use something that exists already?” In that, I can also see a glimmer of hope for the simplicity fanatics where their goal of reuse, clarity in definition and function of elements of the system can be channelled towards preventing a descent into madness. Not done: The same function, component, calculation, logic, etc. that you have just reused.
• Do: Use the right tools for the job. We are lucky to live in an age where there is a myriad of tools and approaches that allow us to analyse, visualise and model complicated and complex. Look for ways to apply learning systems and ones that help you find simpler structures. Not done: Pointless attempts at trying to fit a square peg into a round hole (or the other way around) or effort to carve out the hundreds of pegs out of a wonderful tree you’re are about to cut down. An additional note I cannot resist to add – please, please for the love of all that is holy, do not try to squeeze everything into relational tables.

What do you do to avoid doing unnecessary work?

PS

I think these apply to both complex and complicated in Cynefin Framework. I think these guidelines would also allow business to tap into chaotic areas that I’ve never seen harnessed by any company.

 

Advertisement