Effective
Engineering
e-Newsletter
– 7/02/2009
This is your monthly e-Newsletter from
Effective Engineering Consulting Services
(www.effectiveeng.com).
If you would like to receive Effective Engineering e-newsletters as they are
published, please send an email to
e-newsletter@effectiveeng.com, and we
will add you to our distribution list. Comments and suggestions are welcome
and encouraged!
eN-090702:
“The Perfect is the Enemy of the Good”
By Tom
Dennis – President, Effective Engineering [tdennis@effectiveeng.com]
When you begin work
on a new project it is usually an exciting time when anything seems
possible. Everyone is brimming with new ideas and a strong desire to do
everything right. The initial optimistic view is that this time we’ll
develop the perfect product following the perfect plan using the perfect
team. It would be truly wonderful if that would be the case, but typically
life intervenes to throw you some curves (see
eN-090402 – The Best Laid Plans … and Then Life Happens!).
Aiming for perfection may be a noble objective, but achieving perfection is
another thing entirely. There is a quote from Voltaire from 1764 that
literally translated is, “The best is the enemy of the good.”,
but this is more commonly cited as, “The perfect is the enemy of the
good.” What this means is that pursuing the “best” or the “perfect”
solution may end up doing less actual good than accepting a solution that,
while not perfect, is effective. As you’re undoubtedly aware by now, these
newsletters and my consulting practice are all about effective solutions.
George Patton may have said it a bit better for more modern times: “A
good plan implemented today is better than a perfect plan implemented
tomorrow.” The reality in virtually every case is that perfection
is never realized. People often use the promise of perfection (or the
expectation of perfection) as a rationale for doing nothing, rejecting
actions that would achieve beneficial but not perfect results.
Here’s a fairly simplistic example from my distant past where a “good”
solution enabled a design to move forward quickly where a “perfect” solution
would have taken significantly longer with no real impact on the outcome.
Way back when, in the days before microprocessors (I’m clearly showing my
age ;-)), I was tasked with implementing an iterative algorithm using
gate-level logic that theoretically required a number to be divided by 18.
Well, dividing by 18 in those days was difficult, to say the least.
However, dividing by 16 was trivial, consisting of shifting the binary
number 4 positions to the right. Since the algorithm was iterative, part of
a tracking loop, it homed in on the same result whether dividing by 18 or
16. So a “good” approach took almost no time at virtually no additional
cost, where a “perfect” approach would have taken far longer, at
significantly higher cost, and would have yielded the exact same result.
A good way to think about “good” versus “perfect” can be found in the 80-20
rule that applies broadly to many/most things in life; that is that 80% of
the benefit typically comes from 20% of the work. [In my specific example
above it was more like 99-1; that is 99% of the benefit came from 1% of the
work.] The 80% of the benefit is the “good” solution. The last 20% of the
benefit (achieving the “perfect” solution) most often requires four or
considerably more times the work. People who believe that perfection (100%
benefit) is only slightly more expensive/difficult than good (80% benefit)
are deluding themselves; it simply isn’t true! Perfection is a mirage. You
can’t reach it, and the more you try to get to it, the more time you
waste. More often than not, the time and cost required to achieve
perfection results in a product not being released or a service not being
performed at all. In most situations it is far better to know when good
enough is enough and not to worry about making the perfect choice. It is
better to get something done imperfectly than to do nothing perfectly!
Often, the difference between “perfect” and “good” is an issue of timing.
In the same time period as my example above, our organization at Bell Labs
had a talented group of scientists who developed a large body of work
relating to data communications. They postulated solutions to pressing
problems that were forward thinking, elegant, and solid. However, in many
cases their solutions were substantially ahead of where the technology was.
For engineers like me, their solutions called for a technology (digital
signal processors) that simply didn’t exist at that time. A few years
later, when that technology did exist, their solutions could be implemented
and proved to do everything they said they should do. By then, more
“perfect” solutions were practical and cost effective to implement. Of
course, by then there were new problems, requiring even newer technology
that didn’t exist, and had to wait a few more years for “perfect” solutions
to catch up. In the meantime “good” solutions had to suffice.
I submit that engineering itself is the embodiment of this quote.
Engineering is taking ideas and reducing them to practice. Scientists
generally work in the theoretical realm, developing theories of how things
came about or theoretical solutions to difficult problems. Their
concentration is on developing mathematical explanations of, or solutions to
underlying problems. Their world concentrates on the “perfect”; the
“perfect” explanations and/or the “perfect” solutions. Engineers are the
people who develop practical implementations of what the scientists
postulate. Engineers concentrate on the “good” solutions.
More broadly, most people who live in the real world, as opposed to the
theoretical world, are, like engineers, people who concentrate on “good”
solutions to pressing problems. This involves making practical decisions
that enable the intent of ideas to be implemented even if the perfection in
these ideas can’t. This is true for sales, marketing, services, customer
support, manufacturing, operations, finance, etc. Aiming for excellence is
fine and to be encouraged, but aiming for perfection is plain bad
engineering and business practice.
----
I’d like to thank my old Bell Labs friend, George Scott, from those same
days as discussed above, for suggesting this topic. It is timely and
timeless, and applies broadly to almost anything we do in life.
Copyright © 2009
Effective Engineering Consulting Services, All Rights Reserved
