camdez.com

Rule #1: There are no rules.

Perfectionism: The Engineer's Bane

| Comments

image
(Photo: Paul Mannix)

I’ve tried blogging many times, but my forays into online writing always grind to a halt. The explanation for this is partly psychological and partly technological: I latch onto minor dislikes I have with blogging tools/platforms and I can’t overcome them because of my perfectionist nature. I’d rather leave the blogging ‘problem’ unsolved than to solve it imperfectly.

I have serious difficulties with accepting 90% solutions to problems. I suspect this is a shared engineer trait. 90% solutions are so aggravating because they bring you close enough to perfection that you can nearly touch it—but you can’t quite. It’s like the occasional drop-out in that YouTube video you really wanted to watch that makes you turn the damn thing off completely.

The situation reminds me of roboticist Masahiro Mori’s essay The Uncanny Valley:

There are mathematical functions of the form y = f(x) for which the value of y increases (or decreases) continuously with the value of x. For example, as the effort x increases, income y increases, or as a car’s accelerator is pressed, the car moves faster. This kind of relationship is ubiquitous and easily understood. In fact, it covers most phenomena, so we might think that this function can represent all relations. That is why people are usually upset when faced with some phenomenon it cannot represent.

Climbing a mountain is an example of a function that does not increase continuously: a person’s altitude y does not always increase as the distance from the summit decreases owing to the intervening hills and valleys. I have noticed that, as robots appear more human-like, our sense of their familiarity increases until we come to a valley. I call this relation the “uncanny valley.”

The Uncanny Valley as it applies to robotics (or 3D animation) can actually be quite disturbing, resulting in human-like robots that seem more like zombies or even psychopaths because, (I surmise) the entities in question are similar enough to humans to trigger our brains’ mechanisms for detecting our fellow humans, but not perfect enough to be indistinguishable from actual humans. Our brains essentially detect an impostor.

For a perfectionist, happiness with a design can illustrate this same behavior; a better design makes us happier until it reaches a point (near to perfection) where the flaws in the design seem to stand out in an especially strong way.

Often 50% solutions are actually more desirable (and almost certainly more practically effective) due entirely to these psychological factors. I find that I can adopt a 50% solution thinking “this will work for now”, but I’ll drive myself crazy with a 90% solution I’d view as an imperfect permanent solution. With 50% solutions I’ve psychologically accepted the imperfection; with 90% I haven’t, yet it’s still there.

I’ll try to bring this to a more concrete level:

Until recently I had a storage closet jumble which would have driven me mad had it not had a door which hid its clutter, yet I never did much to permanently resolve the situation. You’d think that I’d take the time to deal with something which irritated me so, but fundamentally, I couldn’t solve the problem. If I needed to retrieve something from the disaster area I’d wade in, find it, and leave with a hefty sigh over the hopelessness of the situation.

The problem was that every time I saw the mess I looked at it as an engineer: it was a problem to be solved. What was the ideal solution? I could put this in one container and that in another, but there weren’t discernible, natural groupings. Which things should go together? They were unrelated! My engineering mind said, “the ideal solution hasn’t yet presented itself, but surely it will”. But it never did.

This is well-explained in the essay on Devizen entitled Programming Can Ruin Your Life:

Programmers become obsessed with perfection. This is why they are constantly talking about rewrites. They cannot resist optimum solutions. Perfection requires tossing aside mediocre ideas in search of great ones. A good programmer would rather leave a problem temporarily unsolved than solve it poorly. A good solution takes into account all predictable outcomes and solves the largest number of them in the most efficient way. This mindset prevents you from writing code with limited utility and life span. While it’s a wonderful trait to have in programming, the demons of scope and efficiency will start to assert themselves on your ordinary life. You will avoid taking care of simple things because the solution is inelegant or simply feels wrong. Time to think will no doubt yield a better result, you’ll say.

Unable to find an ideal solution, I put the project aside and waited for one, until eventually, when the need for space reclamation arose, I stumbled upon the incredibly obvious 50% solution of moving the entire disaster out of my apartment. I’ve been satisfied ever since.

This sounds like the nit-picky, pointless tale of one man’s inability to wrangle his rubbish, but I assure you it’s much more. It’s the tale of a man who has missed important meetings because he can’t find a calendaring application which satisfies his requirements. It’s the story of a dozen stillborn projects.

It’s the face that would have launched a thousand ships but couldn’t find optimal material to make sails from. And for people with this personality trait, it really does matter.

Perfectionism has its charms. Certainly it’s the reason many things are so very good. But if we’re not producing anything because of it, we need to listen to Voltaire’s advice and remember that sometimes, “The perfect is the enemy of the good.”1

When perfectionism has us held hostage, what can we do? Here are three strategies:

“Escape by Design”

I’ve borrowed this title from The Uncanny Valley:

We hope to design robots or prosthetic hands that will not fall into the uncanny valley. So I recommend designers take the first peak as the goal in building robots rather than the second. Although the second peak is higher, there is a far greater risk of falling into the uncanny valley. We predict that it is possible to produce a safe familiarity by a nonhumanlike design. So designers please consider this point. A good example is glasses. Glasses do not resemble the real eyeball, but this design is adequate and can make the eyes more charming. So we should follow this principle when we design prosthetic eyes.

Masahiro Mori is talking about making robots that don’t attempt to look human so that they don’t fall short of looking identical to humans; robots that look like (say) cartoon characters don’t trigger our innate disgust for the flawed (for a deeper treatment of the uncanny valley problem, go here).

In other words, do more by doing less. Accept the “50% solution” as passable with the knowledge (personal or even public) that it isn’t your best work, or wasn’t quite up to your original intention but is still an accomplishment.

Release Iteratively

If you have the luxury of working in a field like (much of) software or web content, release iteratively. Release small, perfected nuggets and build on them later. Don’t ship broken features or immature content, just ship less content and work your way up to the masterpiece.

Make Hard Commitments

Real artists ship, so make big, firm promises to ship the product and stick to them (I’ve done this recently with Raconteur, promising my users an important update before Christmas).

From the 37signals book:

Here’s an easy way to launch on time and on budget: keep them fixed. Never throw more time or money at a problem, just scale back the scope.

This might cause you to release something imperfect (which might even be good for you), or it might just give you the motivation to power through to perfection.

Discussion

Are you held hostage by perfectionism? You know who you are. Can you share any additional tips on freeing yourself from its clutches?

Footnotes

  1. The original quote in French is “Le mieux est l’ennemi du bien.”, from Voltaire’s Dictionnaire Philosophique (1764).

Comments