Too much complexity, not enough simplicity

The title and inspiration of this blog comes from Chapter 3 of John Bogle’s book “Enough: True Measures of Money, Business and Life”. In it, Bogle warns against the dangers of overly complex financial products.  He complains that “Innovation in finance is designed largely to benefit those who create the complex new products, rather than those who own them”.


Bogle advocates the application of Occam’s Razor (thanks to for the post-it note cartoon), the commonly adopted name for William of Occam’s principle that “when confronted with multiple solutions to a problem, choose the simplest one”. As far as financial products go, Bogle says, “Mark me down, too, as an adversary of complexity, complexity that obfuscates and confuses, complexity that comes hand in hand with costs that serve its creators”.

There are many clear parallels to Bogle’s observations in the world of IT and software product development. We often find ourselves inwardly screaming that surely things don’t have to be anything like as complex as they somehow seem to have become, and as a result we can easily sign up to the maxim that “inside every large, complex project is a smaller, less complex project trying to get out”.

Part of the problem, we know, is that complexity is a self-fulfilling prophecy. If we set out assuming that our project might be large and complex, and put in place the processes and resources to handle this complexity, then our project will inevitably become large and complex.

Complexity has been shown to grow exponentially with size. We can easily understand why as process ceremony is layered on process ceremony to produce interim documents for sign-off to justify further significant expenditure, and then more processes layered on top to manage change to these interim documents, and so forth.

For all these reasons we will be well served by adopting agile principles, in particular the principle underlying the Agile Manifesto which states that “Simplicity–the art of maximizing the amount of work not done–is essential”. (Sometimes this is articulated in the form of the “YAGNI” principle from Extreme Programming (XP), that stands “You Ain’t Going to Need It”. I personally am not a fan of this particular turn of phrase, because of its implication that “we” (the developers) know better than “you” (the customer) about what you do and don’t need).

Albert Einstein

A more subtle and powerful maxim relating to simplicity is the famous dictum commonly attributed to Albert Einstein (and sometimes called Einstein’s Razor) that we should always “make everything as simple as possible, but no simpler”.

This rightly implies a warning against trying to make things more simple than they actually are and this is very much something we need to guard against. In particular we must beware quick fixes, silver bullets or the glib application of the same simple practices to increasingly complex problems.

Scrum, for example, is an exemplary management approach because it is incredibly simple and also very effective. If we are facing a situation where a single team can deliver value through a single well-scoped product to meet a cohesive set of needs that can be easily understood and articulated by a single person, then it is just the job. But if we are faced with a large multiple-product, system-of-system type solution to be operated by a large and diverse set of organisations and operate in an environment with a minimum irreducible set of legal requirements and algorithmic complexity, then the belief that all we need to know and do is contained within the Scrum Guide would be pure naivety.

In conclusion, with IT products, just as with financial products, we should indeed apply Occam’s Razor and always look first to adopt the simplest possible scope, process, solution technology and architecture. However, as new complexities and subtleties become apparent, we should not ignore them or try and force fir them into our model by sticking doggedly to our simplistic approach. Instead we must use our professional judgement to constantly adapt our solution thinking to fit our evolving understanding of the situation.

Related content