The Nirvana Fallacy

The nirvana fallacy is the logical fallacy in which something is dismissed after it is compared with an impossibly perfect or utopian alternative.

I’ve seen the nirvana fallacy affecting people’s decision making skills both in terms of software product design and in changing business processes so I decided to talk about both as one topic.

The nirvana fallacy does its damage when we decide to hold out for the perfect solution and ignore opportunities for improvement. Often there is a reluctance to change a current process because the proposed change does not solve every problem, and a reluctance to release software because the software does not do everything or isn’t perfect (yet).

To me this seems to be caused both by perfectionism (and the desire to only project an impression of perfection): “we can’t show that to the customer until it looks perfect” / “we can’t propose that to the board until we know it’ll make a £1 million cost saving” and also from a typical fear of change: the worry of the risk that because making the change does not solve all of the problems with the current situation, we will be judged against the mythical perfect solution.

This feeds procrastination and delays the benefits of incremental changes while we hold out for the ‘perfect solution’: the miracle process without any drawbacks and which rains benefits. In software development this leads us to delay releases until we have polished and gold plated everything even if it could be used now.

Defeating the Fallacy

How do we deal with this? We must accept the need for change to the process and that while not perfect, the change may nonetheless be beneficial. Likewise accept that while the software isn’t perfect yet, we can use it to gain some value or inform some business decision. We must remember that the goal is not necessarily to be perfect but to create some sort of positive impact.

Voltaire said “le mieux est l’ennemi du bien” (‘the best’ is the enemy of ‘good’) and I think that for the short term we should treat ‘good enough to X’ as the goal, where X is some sort of desirable improvement. This isn’t to say that seeking perfection is always bad - it’s good to aim high but don’t let aiming so high put you off making any kind of progress.

Be aware of when you fall prey to the nirvana fallacy in making your decisions - criticise ideas through comparison to realistic alternatives or to no change at all, not to the perfect solution. Compartmentalise problems and accept ideas that provide solutions that don’t solve all of the problems at once.

Fundamentally: accept that no perfect solution exists or even that more value will be created by small and continuous improvements rather than a more expensive and fallible attempt to jump to ‘perfect’. Let go of the need to create something perfect and enjoy the positive impact you can create now and on an ongoing basis as you learn and improve upon the solution.

A Process of Continuous Improvement

Combat perfectionism with science and fear with support: create a culture where experimentation is encouraged; make iteration towards the goal the norm and treat failures as learning opportunities.

Work towards the ‘perfect’ solution in small steps, making reasoned and testable changes. In software, make small releases and in process, make minor changes to flow path/states.

With each change measure the increase in value: value to customer/business, whoever your end user is; in both tangible (sales, customer retention, time taken to complete valuable actions, work item throughput, quality of output) and intangible terms (how do you feel using the software/process, is it easier to do your job like this, is this more enjoyable, has this wasted less of your time).

Above all, if there are improvements to be made then start making them. Could you show something to the customer that doesn’t look perfect but has tested some assumption they’ve made? Could you make a proposal to the board that for now would make only £10k cost savings? Consider the potential lost improvements made by procrastinating or by avoiding non-perfect change. Act! Iterate! Repeatedly evolve the software or process until ROI of change is too low and then move on to something else more valuable.