There is a saying, "The perfect is the enemy of the good", which is often attributed to Voltaire. Essentially it means that if you strive for absolute perfection, you will never actually achieve anything.
This plays a big part in software development, and even more so in indie or side projects. And I'm especially guilty of it.
There is a certain point where the code has reached MVP¹, where it does what it needs to do and where it's possible to maintain it and sort out any problems in the future. When you get there, you should stop. If you are personally invested in the code, you will find it hard, but if you keep going until it's perfect then you'll never get to the next piece of work. And that, in turn, means you'll never finish.
Don't let perfect be the enemy of Good. Aim for Good Enough, for MVP, and make it better later. This way, you'll actually find you progress better, and maybe finish something.
(And, as an added benefit, as you use the code that you think needs improvement, you'll find that maybe your concept of the improvements it needs are off)
1) MVP - Minimal Viable Product. The least work needed to get to market.
Top comments (6)
I am a perfectionist when it comes to my work, i strive for the best in everything i do and it's because i love what i do.
However there are a few things you must know...
The problem is always one of two things...
Instead i recommend trying to deliver a smaller, more focused set of functionality.
Breaking releases down in the chunks will help to you focus on a smaller body of work and have time to refine each area. You can always expand at a later date. By using this method you free up time to be able to think about each area infuences or interacts with other areas.
Like most things, moderation is key.
The problem is that "good enough", "perfection" and "MVP" are not absolute values and might differ among the perspective of a developer, to that of a project manager, a product manager or the customer. Mostly I've seen that a person that argues for "good enough" doesn't understand the missing value perceived by the person who argues for "not done yet".
The book "The Pragmatic Programmer" references an interesting article in the IEEE software magazine from May 1995 by Edward Yourdon entitled "When good enough software is best"
I think you would like it.
It's on my bookshelf already, though I must confess it's been a few years since I last read it and I don't recall that reference. Time to dig it out again I think :-)
Great conversation starter and I heartily agree.
I think this strategy can work at all scales, from a line of code, method, class all the way up to a product, or even a business.
The trick is to balance "Just Good Enough" with "Not Good Enough (Yet)"
"Time, Quality, Cost - Pick 2" is not a static choice, it's a constant dynamic trade off!
I find that three things really help:
1. Maintain a backlog of structured tasks (ie. a tree)
Note down anything, however large or small, that should be done when you spot it. However always strive to work on whatever task pushes you fastest forward.
I use Jira and the Structure plugin to do this, as I'm up to about 2100 issues large and small on a solo project I've been working on for a few years.
Doing this means you relax / de-stress about worrying about the details: "Well I'll get to that if/when it becomes important".
2. Maintain a set of reasonable tests.
No need to be 100% coverage (until MVP?)
Make sure you have unit tests for complex methods and classes.
Make sure you have some system tests for the whole system "works" as you expect at the given point.
Add more tests as you add new or change existing functionality.
Doing this fights the feeling that your project cannot possibly work well enough or as expected: "Well it seems to be mostly working so far."
3. Don't be afraid to refactor at any scale.
Often you'll find that the fast progression means you've learned something that requires you to refactor some code you hastily wrote earlier. This is good! Do it!
Because of 2, you should not be too afraid to even attempt very large scale refactoring if that's required to progress (if not, add it to your list and move on). I am about to finish a huge six month refactoring (planned) because I made something "good enough" while I learned what I really needed to implement.
Doing this fights the feeling that your project is spiralling out of control into a tangled mess of rubber bands, duct tape and super glue. It restores sanity and pride: "Well I'm no longer embarassed to submit this to GitHub or code review."
Shipping beats perfection.