Perfectionism is often seen as a virtue in the software world, but it is a disease.
Perfectionism is a belief that anything less than perfect is unacceptable, and that we should avoid mistakes at all costs. It’s rejection of vulnerability. It results not only in misery, but also cancelled projects and bad products.
It’s not that striving to be outstanding is bad; it’s just foolish to believe that you can achieve great results without exposing yourself to failure. To make good product, you need to start with a small product, and let your users tell you which part of it suck.
Perfectionism kills projects. Often, the vision dreamt up by a perfectionist designer is not feasible to realize within a sensible timeframe, or at all. What’s worse, a perfectionist believes that the product they imagine would be great – but, arguably, it wouldn’t be. It has not been used; it could not benefit from feedback; you just can’t know if it is any good without having a good number of people trying it.
An an industry, we know that starting small and learning from feedback is the way to go – books praising this approach to product development are classics (think “Mythical Man Month”, “Lean Startup”), and “Agile” is the ultimate buzzword. We have known it for decades, but we don’t act like it. It’s still common for software projects to take multiple months before it is ready for the initial release. It’s even more common to fool ourselves that it serves the users better than iterative approach.
Perfectionism can hurt individual programmers in similar way. When we hide from critique, we can’t grow. When we skip the simplest approach that could work and instead immediately reach for overcomplicated ones, we miss the point. It strokes our egos, it makes us look better for other programmers, but It’s not about us; it’s about the users.
There is also the opposite problem – there are plenty of people who don’t give a shit about quality. But that is another story.