Less is more
I’m enough of an Agile nerd to have a favourite Agile manifesto principle. Which is…
“Simplicity — the art of maximizing the amount of work not done — is essential”
It is beautifully put and seems obvious. As users/consumers we crave simplicity.
I’m old enough to remember the early MP3 players, which seemed to use cassette recorders as their template, before layering on additional features that this digital medium could provide. And a few years later the sense of awe that welcomed the simplicity of the iPod, with its single button and dial.
But maximising the amount of work not done should also be at the forefront of our minds when it comes to code, as well as features. As Allan Kelly has highlighted, software development incurs dis-economies of scale. The more code a piece of software has, the more difficult it is to maintain, enhance or fix.
So, why do we do this? Well often because when it comes to selling our services, the assumption is that more is better — more code, more features, more teams, more governance. If we were selling petrol, apples or window-cleaning, it would be fair to assume that the more we could provide for a given fee, the happier our customer would be.
But, it also appears to be human-nature to address problems by adding features, rather than removing them. This fascinating article from nature.com highlights how experiments show that we are inclined to instinctively add more features — even when a simpler (and therefore often cheaper) solution is available.
The article speculates a number of reasons for overlooking ‘subtractive solutions’. These include the assumption that more credit would be received for ‘additive solutions’, which would be considered to be ‘more creative’. But also an assumption that existing features are ‘there for a reason’ and that ‘sunk-cost bias’ could inhibit us from considering removing features.
The implications of this reasoning can be catastrophic. Off-the-shelf platforms are often customised beyond recognition — resulting in organisations being encumbered and constrained by bloated platforms, rather than empowered and enabled by functionality that makes life easier. And technical solutions can be provided which attempt to solve business problems, which could more efficiently be solved by focusing on interactions between individuals.
So, how might we avoid this additive mindset?
The sunk-cost bias mentioned in the article can prevent us from considering the scorched-earth option of starting afresh. And even then we must be mindful of Fred Brooks’ ‘second-system effect’ and Conways’ Law. But this is often the least worst option and can actually represent a Rubicon-crossing moment, where Simplicity is encouraged as the option of choice — an approach Shell benefited from in their ServiceNow implementation.
But more holistically we need to reward team outcomes — rather than individuals’ outputs.
Within an organisation this can mean using Objectives and Key Results (OKRs). These ensure that our initiatives are measureable and aligned with our strategic objectives. And if we are acting as a supplier (agency, systems integrator, etc) this concept should of course be reflected in our commercial/contractual agreements. This not only prevents us from falling into the trap of focusing on outputs and estimation, but also allows us to ask ‘what can we achieve by this date?’. In doing so we encourage our teams to consider the efficiency of simple — even subtractive — solutions.
