Introduction
"Done is better than perfect" is a lesson that I learned from working in a fast-paced competitive startup environment.. and agile software development in general.
Every new codebase I used to touch, I could find some place where something can be improved by using a different data structure, or an algorithm, or some design pattern avoiding nested if-else, or simply abstracting big functions into smaller ones. But as when I started working on big features I came to realize this famous saying.
In this article, I would like to share some of my thoughts on this ideology and hopefully give you some motivation to release your next amazing startup or project you are working on and not get yourself stuck in catch-22.
Perfection
the state or quality of being perfect
In software development world - 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.
Source: The ‘done is better than perfect’ approach to programming - Parker Software
Chasing perfection
If somebody asks me if the system I have developed is perfect or not? I would say comeback after couple of years and ask the same question as I cannot answer it today. Gone are the days where software was sold via floppy disk/DVDs, now software's are getting more personalized and unique to each and every customer. System once perfect needs to evolve with new requirements which one would have never anticipated while designing/developing it.
Over-engineering is often identified with design changes that increase a factor of safety, add functionality, or overcome perceived design flaws that most users would accept. It can be desirable when safety or performance is critical (e.g. in aerospace vehicles and luxury road vehicles), or when extremely broad functionality is required (e.g. diagnostic and medical tools, power users of products).
As a design philosophy, it is the opposite of the minimalist ethos of "less is more" (or: “worse is better”) and a disobedience of the KISS principle. - Wikipedia
Example
Let's say you are a student and as an assignment your teacher asks you to submit a research report on sustainable future or solar energy before next week. If you submit your assignment after the deadline, your marks will get affected even though how in-depth you went into research analyzing sun's orientation, affect of weather, calculating perfect tilt angle, finding how much power output one solar panel can generate, finding return on investment... doing justice to the topic.
Even if your teacher was generous and because of your amazing report gave you full marks. This is not always the case, imagine if this was a question part of your final exam and if you spend all the time answering it so well, you will not get enough time to answer other questions.
Some might argue in the above example a short-crisp, to the point answer would have been perfect. In reality it takes a lot of good efforts, right knowledge and experience, to setup a great foundation and even then you have to adapt to changes and keep on enhancing the product.
Maybe this example is not perfect, so are the projects we work on. There are memes around project requirement not being clear enough. Not everyone is building a medical device where margin of error is a difference of life and death where you have to consider using special tools like ROS to control system clock and scheduler. Not every requirement is like The Thames Barrier must never fail. Here's why it doesn't. - YouTube
Finding the balance
Understand the requirements
Let's say you are working on a feature that will be very important for winter vacation season sale - Chrisman and New Year. Then this is a strict requirement which you have to follow. Christmas is always on 25th of dec. and if your feature is not ready by then business can get affected. That being said not all requirements are strict and it is important to understand them well to avoid doing unnecessary work. Writing good readable code, following coding standards (linters) and writing testcases should be part of requirements of a good tech team and should be caught in code reviews.
Once I was almost about to write a wrapper library on top of RestAPIs of one of our web service. Was it part of the project requirements? - No! Were estimates taken in account for writing the library? - No!
Know your customer
Your customer is the consumer of the features you build. You should be aware of the impact it can have on them not just positively but repercussion if anything goes wrong. This provides sense of responsibility you have, skipping on testcases and not doing non-functional requirements testing reduces your confidence so it is advised to given them attention. Trust me, it makes you happy seeing your customers are happy.
Will customer's care about the technology used? - No/maybe! Will customers have a bad experience if they are not able to login? - Definitely!
What are your expertise
One cannot have knowledge of everything. You should know your boundaries and capabilities. Technology evolves rapidly and it's very hard to keep up-to date with everything. This not only restricted to knowledge of a particular programming-language/framework.
If you are asked to make changes in a totally new codebase, You are no longer an expert and it's your responsibility to get enough context/knowledge from the right person to do full justice to the requirements and communicate this thing clearly to your manager.
Engineering process is a loop
We(Software engineers) have luxury to ship the Minimal Viable Product (MVP) and constantly evolve it incrementally. We do not need to know the final state of the project in the beginning. We should be able to collect necessary feedback and act upon data what works and what does not. This also applies to issues, gives us ability to accept stop gaps while actual fix gets released in next sprint.
Top comments (9)
Getting things out is good. And constant bugs for 6 months is bearable to get the product out the door. What matters is what you do next. That technical debt has to be addressed. Once it's out the door, are you going to continue going at breakneck speed until the code craters and your developers quit in disgust? Or do you take the time to do it right before expanding further?
I pushed a product out the door before it was ready. I went crazy dealing with all the bugs. But, it had been waiting to be released for years, and it needed to be pushed out. We spent 3 years fixing it. After nearly 5 years, it's been modernized and fixed to the point where we can do further significant development on it. Thankfully we have leadership that understands the importance of addressing technical debt.
Do it right the first time. It's the only way. This is why I don't work in a competitive fast-paced startup.
So you like to research into different tools and techniques and come up with the best approach?. Done doesn't mean you introduce bugs, QA is must. Tech debts I can agree can grow and takes time to do refactoring.
I have seen project evolving from just a very simple CRUD into a highly configurable complex business critical logic as the requirements increased.
Yes, I spend a good deal of my personal time doing research on tools and techniques. In addition to learning from mentors, talking to colleagues and keeping up with trends.
I try not to be a perfectionist, for practical reasons. But after that experience, I don't want to do things like that any more. Experience is a great motivator to do better :)
When I started working on this software, it was already a pretty complex beast. The company has grown since then, and the number of users has gone up considerably. The complexity creating by moving to a distributed system alone was a significant hurdle to get over and as you say, the business requirements are constantly evolving. But, as a result of this experience, we introduced a proper DevOps and improved our QA processes.
Thanks for this interesting article.
It might be true that software developers have the prevelige to deliver MVPs, however once the product goes into production, updates become more costly - they must be coordinated with the customer and an implementation process must take place with most upgrades.
No matter how prefect you think your code base is you're always gonna do refactoring later on... you never really done but functional and working is better then prefect 😀👍
This moto is mentioned in the book "Chaos monkeys", the author encountered it while working at Facebook.
I thought it was "Move fast and Break things"
In that book, the head of the Growth department of FB taped (among other rallying cries) "Done is better than perfect" to other people's monitors at work.
NIce ✍ here.