‘The cult of the imperfect’ is, to be short, an acceptance that ‘good enough and available now’ is better than ‘perfect, in a few months time’. We all strive for perfection in our work, but the reality can often be that what’s actually a launchable product sits somewhere between your first prototypes and the vision you have in your head for what will be a 100% final product.

There are many statements and ideas that support this approach. Voltaire is attributed as saying “perfect is the enemy of good”, simply meaning that the (assumed time or cost) implications of striving for perfection will often stop you launching something that could have made a difference when it was simply ‘good’.

You can’t read an article about our tech industry without hearing how people advise to ‘fail fast’ – literally get it out there and if it’s not ready, fail quickly so you can learn from it and move on. We’re also accustomed to hearding about ‘Minimum Viable Products (MVPs) which are the absolute minimum a product or ‘thing’ needs to be for it to achieve its core objectives.

Imperfect delivery takes things one step further than an MVP – not only is it about recognising the absolute minimum your product needs to be to succeed, it also looks at what corners can be cut to get there.

Now to be clear, right from the get-go, that we’re not talking about taking risks, compromising on security or privacy etc. What we’re talking about is bothering a bit less about writing the most optimised code we can, because it takes far less time to write sub-optimal code and fundamentally speaking the outcomes are the same. Again, we’re NOT talking about insecure code, and we wouldn’t expect it to so sub-optimal that it’s basically unusable (that is, by definition, unusable anyway), but what we avoid is the time at the end that seeks to make every last tick of processing power count for as much return as possible.

Why write your own single sign-on solution when there are third party services to do it?

Do you really need a top shelf CMS? Would WordPress not actually fit your needs if you just relaxed a little on your user publishing workflows?

The objectives are to ‘get it done’ and get it shipped, but there are other advantages too. Firstly, less optimised code is almost ALWAYS easier to adapt to do something else, simply because it’s not been finetuned to do one thing in the most optimal way. The second, and probably the most important one, is that you get something out there quickly, from which you can test and learn with real users, and iterate into a better version two…and you’ll still have time and money left from your original ‘perfect project’ budget to do something about it.

And what of the compromises? What do you lose by doing this?

That depends on the decisions to make and what defines your product as ‘good enough’. Sometimes, it’s actually the best possible way to deliver a project anyway, and the only thing you’re really losing is the ability to deliver a project in the old school way of defining scope and timelines up-front. A lot of modern sites and services would actually benefit from quickly launching what can essentially be seen as an alpha and beta version of their site, to help better understand how their users will actually connect with it, and enabling further versions to deliver more of what actually matters, not just what a project team aspired to deliver six months previously.

Sometimes, the outcomes can be more profound, in that it’s possible that you launch today something you know will need significant retooling in the future. Even though hardware resources are relatively cheap at first, they only scale so far before you end up facing the fact that it’s a better idea to rewrite your previous sub-optimal compromises to work more efficiently. But that’s OK.

Why?

Because you get to make the call on when you do that, and you’ll only have to do it because your product has scaled sufficiently that it’s now a problem. That’s not a bad place to be in, and you won’t be alone in making it – facebook’s mobile application is a perfect example of where the decision to keep building it in HTML5, which was up to 5 times slower than developing it using native code, was an acceptable trade-off for the rapid development opportunites that the approach gave them, and it wasn’t until the app had matured significantly that they finally swapped to the more optimised way of coding.

Remember – imperfect delivery is not about adding more risk, or security concerns, or even really about accepting compromises within your project itself. It’s about focusing on what you actually need – which you should be doing anyway – and then looking at how you can get that to market as quickly as you can, taking compromises in areas such as optimisation so that you can deliver today what, in a perfect project, might have taken until next week.

With that approach to project delivery, you can find your product gets to market quicker, for less money, and ultimately benefits from better feedback, sooner, than if you’d waited to launch the ‘perfect’ product in the future.

Back to the blog listing