7/31/2019 Rx010 Complexity in Design

1/3

10 Computer

A MODNART

Pu b l i sh e d by th e IEEE Co mpu te r So c ie ty

A

t its most basic, what engi-neers do is pit their intel-

lect, training, experience,and intuitionand that oftheir design teamsagainst

an implacable, relentless adversary:nature itself. I dont mean that an actualbattle is going on; after all, only one ofthe would-be combatants even knows(or cares) that there is any contest.

When nature is the adversary, all thatstands between the engineered productand disaster is the product designersforesight, wisdom, and skill. Naturemay not have maliciously chosen justthe right wind pattern to demolish theVerrazano Narrows Bridge, but bridgesmust not fall down no matter how thewind is blowing. It may not literally betrue that nature is conspiring againstyou, but its a very good way to viewthe general engineering challenge.Forewarned is forearmed.

Students of engineering are firsttaught to follow the rulesguide-lines for design that have proven overtime to result in systems that behave asintended. Civil engineers learn abouttraffic patterns and human driving

behaviors so they can design betterroads. They study strengths of materi-als so that their bridges will be eco-nomical and reliable. When a bridgecollapses, the rules are changed toincorporate the hard-won learning.

THE ART OF ENGINEERINGBut thats not all there is to it. If engi-

neers only had to follow a set of direc-tions, we wouldnt need engineers;computers and robots can do that

much. The real art of engineering, itssine qua non, is in evaluating a pro-posed design from every angle andvantage point to make sure a designwill achieve its goals and prove reliableover its intended lifespan.

When a simulation says a design isworking, ask whether the simulation is

correct and complete. If a formal proofasserts that some aspect of the designis correct, ask whether the proof itselfis trustworthy. What makes you so surethe implementation technology willwork as needed? What if the productspecification itself has holes or blindspots? What if your products buyerslike it so much that they begin using itin ways you hadnt intendedcan youanticipate that so the product willgracefully accommodate its new uses?

If the designer knows what shesdoing, the design incorporates existing

loreonly the desperate or suicidallynaive would attempt a product with nofamiliar or known-trustworthy com-ponentsbut it cant be based only onknown components.

The nature of engineering is to neverdesign exactly the same thing twice.Every new design pushes the envelopesomewhere: performance, cost, relia-bility, features, capacity. Inevitably,some aspects of the new design will beoutside the existing experience base.Thats the part of engineering you

dont learn in school. And assumingtwo competing design teams are tech-nically proficient and reasonably wellled, its what these teams decide to doin these unknown areas that willlargely determine which design ulti-mately triumphs.

So how do you handle the wilder-ness areas of your design, those placesbeyond your comfort zone and thesafety of your tools and direct experi-ence? I think the answer comes downto how well you handle complexity.

WHAT IS COMPLEXITY?People who study chaos theory speak

of a related complexity theory. Theyretrying to figure out why certain pat-terns seem to appear at many differentlevels of abstraction in natural phe-nomena; fractals are an example.

Scientists and engineers learn earlythat patterns often mean somethingimportant, so when the chaos theoristssee the same pattern appear in seem-ingly unrelated places, they sense thatthere is something here worth investi-

gating. However, I dont know if theway they use the word complexityis what I mean by that word. Theyadopted the term before I did, but Idont know of a better one, so for thesake of discussion, lets assume thechaos folks are chasing a differentchimera than I am.

Even though you cant tell it by look-ing at the math they use, physicistsstrongly prefer simplicity in their mod-els. Dissatisfaction with the particle

Complexityin DesignBob Colwell

How well you

handle your

design comes

down to how

well you handle

complexity.

7/31/2019 Rx010 Complexity in Design

2/3

October 2005 11

zoo that had accumulated over timeled Murray Gell-Mann to look for a

simpler underlying structure, which henamed quarks.

Physicists know well the pattern bywhich an imperfect understanding ofwhat nature is exhibiting often leads toa complicated, unsatisfying scientificmodel that a simpler, more fundamen-tal model will eventually replace. Thetendency for better knowledge to leadaway from complexity and towardsimplicity is a useful signpost for theirintuitions (www.santafe.edu/sfi/People/mgm/complexity.html).

Another group that adopted theword complexity is wine connois-seurs. When they say a wine is com-plex, they mean they think it tastesgood, and it strikes a good balancebetween all the different ways a winecan be measured. (Rich and deep, oakywith a hint of fresh bougainvillea blos-soms after a rainstorm on a Tuesday.Okay, I admit itI dont know any-thing about wines, and I made that up.But they may as well say that as whatthey do say about wines, for all it helpsme in selecting one. Dry wines still

stain the rug.) I doubt that the wineexperts have much to offer design engi-neers in terms of identifying and prop-erly handling complexity, other than inmuch-appreciated liquid form.

A fourth group that I mention withconsiderable trepidation are the intel-ligent design proponents. I do thinkthere are ideas here that can inform adesign teams choices, if only we candistinguish the essence of the irre-ducible complexity argument from theemotional tar pit from which it comes.

Irreducible complexityThe basic notion of irreducible com-

plexity is that, to achieve some end,certain physical systems must have aminimum amount of complexity. Noisolated pieces of that system are veryuseful in and of themselves, but takenas a whole, they could achieve some-thing very useful indeed.

Ive heard human eyesight describedin this way, for example: Without a

clear cornea, nothing else matters. Butif all you had was a cornea, without

the light-sensitive rods and cones, youstill couldnt see. And if you have acornea plus light-detecting facilities,you still need a neural pathway tocarry the information and someamount of mental processing withwhich to interpret it.

The intelligent design communityuses such arguments to attack evolu-tion, expressing incredulity that some-how all the necessary pieces coulddevelop together when none of themare useful until the whole mechanism is

complete. Its an interesting argument,and there are reasonably compellingcounterarguments, but its not myintention to take on this debate here. Imention it only because I want to bor-row the idea of irreducible complex-ity, and attribution must be given.

Quantifying complexityYou cant quantify complexity, but

you can feel it. In fact, during a lead-ing-edge design, if anything, complex-ity feels more real than many of thedesigns more quantifiable aspects.Your simulation tools can tell you amicroprocessors projected die size, buttheres still time before the tapeout.Things happen, and as long as youbelieve that aspect of the design is on

track, then for today its mainly a the-oretical concern.

Performance and power dissipationfeel that same way. But complexity isa monster you can hear breathing rightoutside your cubicle. It whispers yourname during planning meetings, but ifyoure not paying attention you maynot hear it. Later on, you find yourselfat the moment of truth in a project,suddenly realizing that things arentright and its by no means clear if there

is a way to salvage them, let alone whatthat way might be.

Complexity factorsThere are some hallmarks to com-

plexity that Ive noticed over the years.I believe design complexity is a func-tion of the

number of ideas you must hold inyour head simultaneously;

duration of each of those ideas;and

cross product of those two things,times the severity of interactions

between them.

For instance, all else being equal, adeep microarchitecture pipeline carriesmore intrinsic complexity than a shorterone. Different activities occur at eachpipe stage (otherwise why does thatpipestage exist?), and each activity cantake more than one clock cycle. If apipestage doesnt exist, it cant interactwith any others; conversely, if thepipestage does exist, you must considerthose interactions and make sure theyreall congruent with the projects goals.

For nominal pipeline operation, thiskind of analysis is difficult but doable.But for exceptional conditions, such asreset, fault, interrupts, test scan, per-formance counter interactions, power-downs to lower thermals, breakpoints,and stalls, the degree of intellectual dif-ficulty can reach nightmarish propor-tions.

Project unknownsThis definition of design complexity

makes it a little clearer why project suc-

cess is so sensitive to unknowns. Thevery fact that these unknowns are, well,unknown, means that they could injecta wide range of behavior into thedesign. That uncertainty range increasesthe number of ideas you must simulta-neously consider, and it might alsoincrease the predicted time durationsneeded.

It doesnt take much uncertainty tomake the complexity-derived behaviorrange too big to mentally handle. And

An engineersimplacable, relentless

adversary is natureitself.

7/31/2019 Rx010 Complexity in Design

3/3

12 Computer

A t R a n d o m

this is perhaps the most insidious issueof all: When faced with a complex sit-

uation, you generally know that youarent yet in command of all the neces-sary details. This in itself isnt alarm-ing; it takes time to understand whathundreds of people are doing or intendto do. But you cant leave it like that.

One option is to insist that all of theunknowns be researched and quantifiedso that your spreadsheet can tell youwhat to do. But this scheme doesntwork. Your project doesnt have enoughtime or idle engineers to do this muchnew work; besides, not everything you

want to know about your project isknowable, much less quantifiable.Complexity exacts a toll in many

ways. In my January 2004 At Randomcolumn (Design Fragility, pp. 13-16),I argued that complex designs are morefragile and lead to more surprises(which are always bad). Complexityleads to longer development schedules;it directly causes design errata; it fos-ters suboptimal tradeoffs between com-peting goals; it makes follow-on designsmuch more difficult; and its cumula-tive, with new designs inheriting all of

the complexity of the old and with newcomplications layered on top.

Increased project complexity alsoshrinks the available pool of engineerswho can help when things go awry.Any competent designer can make easy,straightforward choices, but for trulygnarly situations, only wizards will do.And there are never enough wizards.

Stanfords John Hennessy once saidthat its always possible to design some-thing so complicated that you can neverget it right. As a project leader, are you

smart enough to mentally absorb theremaining project unknowns on top ofwhat you already know to the extentnecessary to make good decisions onany remaining tradeoffs (some of whichhavent even surfaced yet)?

To some extent, everyone on thedesign team has this same problem. Inconsidering a designs overall com-plexity, youre making the smartenough choice on their behalf as well.If, after deep reflection, you believe you

have a practical grasp of the projectscomplexities, with enough margin to

handle the usual surprises down-stream, great. Today will be a good dayand you wont have to think about thisagain until next week, when you mustconfront the same issue again. Butwhat if you decide that things seem tohave gotten a bit too close to the edge?What do you do then?

WHY NOT JUST SIMPLIFYEVERYTHING?

Why not just make everything sim-ple? As Einstein said, everythingshould be as simple as possible, but nosimpler.

Have you ever taken a close look atan acoustic grand piano? The compli-cated mechanism in which the playersfingers cause hammers to fall on

strings, which are damped to varyingdegrees and at varying times, is exquis-itely subtle and quite involved. Perhapstheres a way to simplify that mecha-nism without sacrificing the combina-tion of tone and playability that hasselectively evolved over hundreds ofyears. But it seems likely that most ofa pianos complexity is necessarybecause of how our fingers, feet, andears work. A skilled performer cancoax thunderous waves of sound ordelicate susurrations; the mechanics of

the keys have the requisite dynamicrange. This complexity works.

A simple bow and arrow can be eas-ily made; if the materials and work-manship are good, a serviceableweapon can be achieved. But there areother variations on that theme thatwork bettera compound bow usingpulleys achieves much higher arrowspeed at less draw weight, but at thecost of considerably higher complex-ity in its design. For what it achieves,

Its always possible todesign something socomplicated that you

can never get it right.

that complexity is well justified.Its also true that what initially looks

impossibly complicated may seemquite reasonable after a period of studyand experience. In part, you just getused to it; you find that you canremember the various pieces, theirroles, and how they interact. You alsofind ways of thinking about what thosepieces do, mental models that youinternalizethus they constitute notax on your cognition.

I remember how thunderstruck Iwas in college after struggling withsome formidable mathematical con-

cept only to have a fellow studentpoint out how simple it was whenviewed in the right way. This familiar-ization effect must also be consideredwhen youre judging how much com-plexity a design project should include.

Adesigns complexity must servea projects major goals. If yourdesign is complicated but coher-

ent, challenging but understandable,you may have struck a good balancebetween irreducible complexity and

the projects goals.Strive to avoid creeping complexity,

the kind that arises from unintendedinteractions among multiple unrelateddesign decisions. Eschew complicatedmachinery that isnt clearly and prov-ably necessary to attain one or more ofthe major project goals. If you arentsure you need some logic in yourdesign, keep asking questions untilsomeone either justifies it or agrees totoss it overboard.

Entropy always drags a project in

the direction of increasing complexity;things never get simpler on their own.Except for bad wine. On Tuesdays. I

Bob Colwell, the 2005 recipient of theIEEE Computer Society/ACM Eckert-Mauchly Award, was Intels chief IA32architect through the Pentium II, III,and 4 microprocessors. He is now anindependent consultant. Contact himat bob.colwell@comcast.net.