IEEE Spectrum July, 2009 - 19

reflections

By--roBert--w.--lucky

--
wicked--
problems

trol, pretending that no effects
propagate beyond this box.
Perhaps all real
engineering problems are
in some sense wicked, but
many critical problems in

S

MGM/THE KOBAL COLLECTION

ome problems
have such complex
social, economic, or
organizational interactions
that they can't be solved fully.
They've become popularly
known as "wicked problems."
I'm not fond of these
problems, though I've seen
my share of them-they seem
to be ubiquitous in systemsengineering design. However,
I'm fascinated with the name.
It reminds me of "fuzzy logic,"
a brilliant and oxymoronic
phrase that juxtaposes an
adjective connoting warmth
and softness with a noun
that implies something cold
and mechanical. In "wicked
problem," an adjective
meaning evil or sinful,
usually assigned to humans,
is attached to an abstract,
inert noun. The name
suggests that the problem
itself is consciously malicious.
It knows that someone is out
there working on it, and it
is going to stop that person
from getting anywhere.
Wicked problems are
unsolvable not because they
are mathematically difficult
but because we can't define
them well enough to quantify
things. We don't encounter
such problems in our
engineering education, where
all the exercises have solution
paths, usually to precise
numerical answers. If only
the real world were always
so obliging! I am reminded
of Douglas Adams's famous
fictional supercomputer built
to answer the one question:
"What is the meaning of life?"
www.spectrum.ieee.org

This surely is the mother of all
wicked problems. As many
readers of The Hitchhiker's
Guide to the Galaxy know,
after long consideration
the computer returns the
answer "42." We sometimes
give similar oversimplified
solutions to problems
that are, well, wicked.
Invoking another
evocative name from modern
physics, wicked problems
demonstrate entanglement:
What we do here influences
something else way over there
in some mysterious way that
we don't fully understand.
When the ramifications of
our design extend beyond
our organizational, knowledge, technical, or authority
boundaries, we partition the
problem and draw a virtual
box around the part we con-

government may be especially
so. Consider airport security.
Every time I take off my
shoes and walk through
that strange freestanding
doorway, I think there must
be a better way. But we
lack the data needed for an
engineering solution. We can
try to calculate the costs and
benefits: We know the salary
and equipment expenses,
and we can measure the
probabilities of missed
detection and false alarms.
But the true cost of the system
should include the lost time,
uncertainty, and aggravation
of millions of airline
passengers, as well as the
lost revenue from would-be
passengers who are thus
discouraged from traveling,
and so forth. These costs
would have to be weighed

against the incalculable
cost of failing, even once, to
prevent an airline disaster.
To make matters worse, we
understand only poorly the
motivations and plans of
potential hijackers. And as
in almost all such problems,
there is an overriding
question-if we didn't spend
the money here, where
might it be better used?
On the other hand, what
would be the costs to society
if the public at large lost
confidence in air safety and
stopped flying altogether?
Problems in allocating
defense acquisition funds
are similarly wicked. For
example, what are the costs
and benefits of improving
the surveillance capabilities
of drone aircraft versus
investing in satellite
technology? Each promises
better intelligence, but what is
a pound of intelligence worth?
Isn't the ultimate objective
to win the war? But what
war did you have in mind?
And what did you mean by
"win"? The unanswerable
questions ascend into the
skies, far above your pay
grade, whatever it may be.
Because such problems
are wickedly unsolvable, the
practice is to set immutable
specifications for the constituent subsystems, leaving
little opportunity to trade
off cost, performance, and
scheduling parameters-
and leaving equally little
room for the analytical and
methodical approach that is
the essence of engineering.
Wicked problems will
never be solved in the conventional sense, but we
engineers should do our
best to bring this kind of
thought to any problem, be
it wicked or not.
o

july 2009 * IEEE SpEctrum * NA

27
http://www.spectrum.ieee.org
Table of Contents for the Digital Edition of IEEE Spectrum July, 2009
