When you’ve developed a working product, it’s normal to take pride in its performance— you’ve worked hard on it. It’s normal to want to hold off on release until it’s got this feature, or that’s been tweaked, or it’s gone through yet another round of testing. In short, it’s perfectly normal to pursue perfection.
It is notoriously hard to declare a software product, project, or even a single feature ‘finished’. There’s always something else that could be finetuned, or added, or upgraded. This makes it incredibly difficult to take the leap to release.
In today’s competitive market, though, can you afford to release your product before it’s perfect? Well, the ‘done is better than perfect’ approach suggests that you can’t afford not to. Perfectionist programmer or not, here’s why you should consider the ‘done is better than perfect’ approach.
Done is better than perfect
‘Done is better than perfect’ is a maxim made popular by Facebook COO Sheryl Sandberg. In her book, she refers to the motto as a reminder to let go of impossible standards. She writes that: “Aiming for perfection causes frustration at best and paralysis at worst.”
The concept is not so very different in a coding context. The ‘done is better than perfect’ approach to programming is the idea that a released software product is better than an unreleased product. It focuses on completing a product and having the courage to share it, rather than getting lost in minute details and endless iterations.
The ‘done is better than perfect’ approach, then, is a mindset that challenges perfectionism. It drives us to recognise when our software is good enough, and it pushes us to get each new project ‘out there’. When you’re not busy agonising over intricacies, you can get busy building a customer base and solving the core pains you set out to solve.
That doesn’t mean to say that the ‘done is better than perfect’ approach equates to complacency. It’s not a reason or excuse to release a bad product. The software you release should be able to solve the pain points that it’s designed to answer. It needs to be a good product, it just doesn’t need to be perfect. After all, is there ever any such thing as a ‘perfect’ product?
Perfectionism pitfalls
Without adopting the ‘done is better than perfect’ mindset, you can easily fall foul of perfectionism. And unfortunately, perfectionism is an affliction that comes with more than a few major downsides for your software and your business.
For a start, ‘perfect’ simply takes too long to develop, meaning that it could end up never being released. There will always be something else to tweak. Plus, with technology advancements moving so quickly, pushing for perfection can often leave you working on outdated software and continually playing catch up.
Striving for perfect sets an unattainable goal, based on the need for your product to be liked. It makes sense, on the one hand. After all, you want your customers to love your product, and it can be hard to see that they would do that unless it’s perfect. But perfect is subjective. It’s difficult to align your view of ‘perfect’ with a customer’s perspective, and even more difficult on a granular user by user level. No two users will have the same view on what precisely makes for perfect.
Perfectionism also means you run the risk of software plagued with feature creep. With every new capability that you add in your quest to make that elusive ‘perfect’ product, the core function of your software becomes more crowded and buried. You end up with a mess of functionality that brings no long-term value or competitive edge to your product.
It’s also worth remembering that having a perfect product isn’t the only thing that guarantees success. Does your product efficiently solve a problem? Is there a viable need for it in the market? Key questions such as these are more important than striving for perfection.
Why done is better than perfect
Adopting the ‘done is better than perfect’ approach means that you can get your product out there. When you release your ‘good enough’ product, you start building your customer base, generating a return from all your hard work and efforts.
Along the way, you learn more about the market that your software appeals to. You create the opportunity to collect feedback. In all likelihood, you could discover that the ‘perfect’ you were originally striving for was the wrong one anyway. You might even attract an unexpected audience, or uncover unexpected popularity in certain features or functionality.
A released product means that you now have something to build on. As the saying goes, ‘perfect is the enemy of good’. A supposedly ‘perfect’ software product, once released, won’t lend itself to being improved. A ‘good enough’ product, however, motivates us to improve on it. It lends itself to upgrades, to new tech, to innovation – instead of being a finished product aging into obscurity.
Your products are only ever drafts
The ‘done is better than perfect’ approach to programming is a mindset that reminds us that the products, software and services we release are drafts of the next one. Instead of trying to release the ultimate product in one go, we can release something that’s good enough, and build on it, update it and improve it as we go.
There is nothing wrong with taking pride in your product. Equally, there is never an excuse to ship shoddy, substandard code that you will have to re-do all over again. This is not what the ‘done is better than perfect’ approach is about.
It’s about recognising when your product is good enough. At some point, you have to be able to acknowledge that a product may not quite be absolutely, unequivocally and breathtakingly ‘perfect’ – but that it’s still pretty darn good.
Originally published here: https://www.parkersoftware.com/blog/the-done-is-better-than-perfect-approach-to-programming/
Top comments (1)
this is a nice post, and i like the way you've written this. however this is the prototyping method. I think that getting a "done" product out there is very important, but also think that during the stages of iteration there has to be refinement of the existing code with each iteration. This sometimes happens with time (e.g. a new feature requires redevelopment of existing code).
There should also be no excuse for poor quality code. I'm not saying eveyrone has to know everything (E.g. if you don't know regex, can you tool something efficient and effective that does the same thing), but commenting, readability and flow should always be in the forefront.