Done is better than perfect is a motto popularised by Sheryl Sandberg, COO of Facebook. In her book Lean In, she stated this as a way to ‘let go of unattainable standards’.
How can we as developers use the key message behind this motto to our advantage?
The nature of software development means a product is never truly ‘done’. There’s always something to be tweaked, features to be added, optimisations to be made and bugs to be fixed.
For programmers, done is better than perfect does not mean purposely releasing subpar software but rather, it’s being wiser at defining what constitutes something as ‘done’.
The concept of done is better than perfect in the context of software development gives a fresh new perspective on how developers can choose to handle the delivery of projects. It allows letting go of those unattainable standards and embracing imperfection to a reasonable extent.
This is an article to provoke some thoughts within you as a developer to evaluate why done is better than perfect can be a powerful mindset to adopt.
We’ll discuss how the concept behind done is better than perfect can be used to your advantage. And how it should, or should not be used to change your approach in the delivery of software projects.
Done is better than perfect is at the core of learning
If you’re a developer you had to start from somewhere. There was a time when you were completely new to programming and had to learn the skills needed.
Now have you ever thought, ‘at what point did I perfect my programming skills?’
If your answer is never, that would be correct.
Let’s face it, in reality skills can’t be perfected. You can spend your entire life working on a particular skill but it can’t reach the stage of perfection as nothing in this world is perfect.
The same of course applies to programming. Whether you’re just starting out or you’re picking up a new language or framework, perfection is not attainable.
That’s why embracing imperfection is a crucial mindset to accept as you won’t waste time aiming for some level of perfectionism before putting your skill to use.
If you’re learning something through courses and tutorials, you don’t have to grasp everything in it 100% before you move on to actually putting what you’re learning to use.
It’s not uncommon for developers to get stuck in the learning phase and to stall at moving on to creating projects when the time is right. In what is known as tutorial purgatory, this can prevent you from moving on to the next stage of your learning process of starting to apply what you’re learning.
“If you look for perfection, you’ll never be content.” – Leo Tolstoy
So the concept of done is better than perfect can certainly be applied here to ensure you move from practice to application and use put those newfound and imperfect skills to use as soon as possible.
Done is better than perfect combats over-engineering
If you’ve been involved in a project from start to finish before you’ll know it’s tricky to define anything as ‘done’.
One of the causes of this is over-engineering, which is allowing the scope of the project to grow because there’s always that one more feature to be added.
However, it’s important to know when to draw a line between the minimum requirements and ‘nice to haves’.
Failing to do this will lead to over-engineering and in turn result in missing deadlines as you’re unable to deliver the scaling scope of the project.
How does the motto of done is better than perfect help out here?
With this in mind, you’ll know there should be a point when you or your team accepts not all features can make it into the product release.
Know when to stop adding features or tweaking that one thing and keep your targets within a reasonable scope.
Deadlines also work to your advantage here. Set deadlines and use them to keep focused on the original scope of the project.
So the next time you’re tempted to add that one more feature to the project scope, remember that done is better than perfect.
Imperfection drives the idea of an MVP
An MVP (Minimum Viable Product) is a process used to describe the intention of delivering a product containing the bare minimum functionality to meet only the core requirements.
Although MVPs may not always be production-ready on paper, they are released to end customers nevertheless as a way of launching a product into the market early and more importantly, to receive early feedback.
Collecting this early feedback is invaluable as it will contain direct information on what the expectations of the market are which can be used to drive future development.
This will greatly improve the efficiency of a product development cycle as less time can be spent on trying to guess what the market actually wants.
“Strive for continuous improvement, instead of perfection.” – Kim Collins
We can certainly see how done is better than perfect applies for MVPs as it means embracing incompleteness and purposely launching something you know is far from perfect.
What happens if instead you choose to assume you know what the market wants and deliver a product without taking any feedback into consideration?
In this case, your attempt to ‘perfect’ it before the customer sees it will likely end up with the realisation that the product is far from perfect in the eyes of the customer.
The idea of peeling back your product and delivering something not fully functional on paper might not sound appealing to all.
However, think long-term. It’s purposely limiting and delivering that far-from-perfect product with the intention that it will ultimately allow delivery of something closer to perfect in the long run.
Imperfection doesn’t equal defective
While done is better than perfect encourages embracing of imperfections, it doesn’t give an excuse to release defective products!
It can be easy to abuse its meaning to imply releasing a bug-ridden or flawed software product is okay if you’re going to fix it later.
However, there’s a huge difference between not-perfect and not-functional!
If you still choose the path of knowingly delivering a defective product, remember that Technical Debt is real and lurking. And it’s only a matter of time before the consequences of Technical Debt will need a hefty repayment.
Instead, think of using the idea behind done is better than perfect to place the right level of priority on how time should be allocated. This will ensure there’s enough time for appropriate functionalities of the product to be developed to a reasonable standard.
Place your effort in getting clarity on the requirements which are critical to your end users. Then ensure enough resources can be allocated to deliver those functions in a working state when presenting a first draft of the MVP.
The key is finding the right balance between a product that may have imperfections but still safely meets the core requirements of the end customer. The process of requirements gathering is not one related to the activity of coding but is an essential non-technical skill for developers.
So while done is better than perfect allows imperfection, it is a controlled level of imperfection. It should not be an excuse to compromise quality or reliability.
Conclusion
Done is better than perfect is a powerful motto that embraces imperfection as a way of avoiding time-wasting by trying to gain something unattainable.
When applied in the context of software development, done is better than perfect can be used to put new skills to use sooner, prevent over-engineering and enable the ability to launch products into the market earlier.
Overall, developers can use the idea behind done is better than perfect to stay focused and greatly increase efficiency in the delivery of projects.
The key point to remember is: if perfectionism is the aim, nothing will ever get done!
In what way does the motto of done is better than perfect resonate with you? Let us know in the comments.
See other articles you may be interested in below: