1/6/2015

Big Ball of Mud

BigBallofMud
BrianFooteandJosephYoder
DepartmentofComputerScience
UniversityofIllinoisatUrbanaChampaign
1304W.Springfield
Urbana,IL61801USA
foote@cs.uiuc.edu(217)3283523
yoder@cs.uiuc.edu(217)2444695

Saturday,June26,1999
FourthConferenceonPatternsLanguagesofPrograms(PLoP'97/EuroPLoP'97)
Monticello,Illinois,September1997
TechnicalReport#WUCS9734(PLoP'97/EuroPLoP'97),September1997
DepartmentofComputerScience,WashingtonUniversity
Chapter29
PatternLanguagesofProgramDesign4
editedbyNeilHarrison,BrianFoote,andHansRohnert
AddisonWesley,2000
ThisvolumeispartoftheAddisonWesleySoftwarePatternsSeries.
Thispaperisalsoavailableinthefollowingformats:
[PDF][Word][RTF][PostScript]
AlsobyBrianFooteandJosephYoder
Architecture,Evolution,andMetamorphosis
TheSelfishClass
ThispaperwastwicefeaturedinSlashdot

Contents
1. Abstract
2. Introduction
3. Forces
4. BigBallOfMud
5. ThrowawayCode
6. PiecemealGrowth
7. KeepItWorking
8. ShearingLayers
9. SweepingItUnderTheRug
10. Reconstruction
11. Conclusion
12. Acknowledgments
13. References
http://www.laputan.org/mud/

1/36

1/6/2015

Big Ball of Mud

Abstract
Whilemuchattentionhasbeenfocusedonhighlevelsoftwarearchitecturalpatterns,whatis,ineffect,the
defactostandardsoftwarearchitectureisseldomdiscussed.Thispaperexaminesthismostfrequently
deployedofsoftwarearchitectures:theBIGBALLOFMUD.ABIGBALLOFMUDisacasually,even
haphazardly,structuredsystem.Itsorganization,ifonecancallitthat,isdictatedmorebyexpediency
thandesign.Yet,itsenduringpopularitycannotmerelybeindicativeofageneraldisregardfor
architecture.
ThesepatternsexploretheforcesthatencouragetheemergenceofaBIGBALLOFMUD,andthe
undeniableeffectivenessofthisapproachtosoftwarearchitecture.Whatarethepeoplewhobuildthem
doingright?Ifmorehighmindedarchitecturalapproachesaretocompete,wemustunderstandwhatthe
forcesthatleadtoaBIGBALLOFMUDare,andexaminealternativewaystoresolvethem.
AnumberofadditionalpatternsemergeoutoftheBIGBALLOFMUD.Wediscusstheminturn.Two
principalquestionsunderliethesepatterns:Whyaresomanyexistingsystemsarchitecturally
undistinguished,andwhatcanwedotoimprovethem?

Introduction
Overthelastseveralyears,anumberofauthors[Garlan&Shaw1993][Shaw1996][Buschmannet.al.
1996][Meszaros1997]havepresentedpatternsthatcharacterizehighlevelsoftwarearchitectures,such
asPIPELINEandLAYEREDARCHITECTURE.Inanidealworld,everysystemwouldbeanexemplar
ofoneormoresuchhighlevelpatterns.Yet,thisisnotso.Thearchitecturethatactuallypredominatesin
practicehasyettobediscussed:theBIGBALLOFMUD.
ABIGBALLOFMUDishaphazardlystructured,sprawling,sloppy,ducttapeandbailingwire,
spaghetticodejungle.Weveallseenthem.Thesesystemsshowunmistakablesignsofunregulated
growth,andrepeated,expedientrepair.Informationissharedpromiscuouslyamongdistantelementsof
thesystem,oftentothepointwherenearlyalltheimportantinformationbecomesglobalorduplicated.
Theoverallstructureofthesystemmayneverhavebeenwelldefined.Ifitwas,itmayhaveeroded
beyondrecognition.Programmerswithashredofarchitecturalsensibilityshunthesequagmires.Only
thosewhoareunconcernedaboutarchitecture,and,perhaps,arecomfortablewiththeinertiaoftheday
todaychoreofpatchingtheholesinthesefailingdikes,arecontenttoworkonsuchsystems.
Still,thisapproachenduresandthrives.Whyisthisarchitecturesopopular?Isitasbadasitseems,or
mightitserveasawaystationontheroadtomoreenduring,elegantartifacts?Whatforcesdrivegood
http://www.laputan.org/mud/

2/36

1/6/2015

Big Ball of Mud

programmerstobuilduglysystems?Canweavoid
this?Shouldwe?Howcanwemakesuchsystems
better?
Wepresentthefollowingsevenpatterns:
BIGBALLOFMUD
THROWAWAYCODE
PIECEMEALGROWTH
KEEPITWORKING
SHEARINGLAYERS
SWEEPINGITUNDERTHERUG
RECONSTRUCTION
WhydoesasystembecomeaBIGBALLOFMUD?
Sometimes,big,uglysystemsemergefrom
THROWAWAYCODE.THROWAWAYCODEis
quickanddirtycodethatwasintendedtobeused
onlyonceandthendiscarded.However,suchcode
oftentakesonalifeofitsown,despitecasual
structureandpoorornonexistentdocumentation.Itworks,sowhyfixit?Whenarelatedproblemarises,
thequickestwaytoaddressitmightbetoexpedientlymodifythisworkingcode,ratherthandesigna
proper,generalprogramfromthegroundup.Overtime,asimplethrowawayprogrambegetsaBIG
BALLOFMUD.
Evensystemswithwelldefinedarchitecturesarepronetostructuralerosion.Therelentlessonslaughtof
changingrequirementsthatanysuccessfulsystemattractscangraduallyundermineitsstructure.Systems
thatwereoncetidybecomeovergrownasPIECEMEALGROWTHgraduallyallowselementsofthe
systemtosprawlinanuncontrolledfashion.
Ifsuchsprawlcontinuesunabated,thestructureofthesystemcanbecomesobadlycompromisedthatit
mustbeabandoned.Aswithadecayingneighborhood,adownwardspiralensues.Sincethesystem
becomesharderandhardertounderstand,maintenancebecomesmoreexpensive,andmoredifficult.
Goodprogrammersrefusetoworkthere.Investorswithdrawtheircapital.Andyet,aswith
neighborhoods,therearewaystoavoid,andevenreverse,thissortofdecline.Aswithanythingelseinthe
universe,counteractingentropicforcesrequiresaninvestmentofenergy.Softwaregentrificationisno
exception.Thewaytoarrestentropyinsoftwareistorefactorit.Asustainedcommitmenttorefactoring
cankeepasystemfromsubsidingintoaBIGBALLOFMUD.
Amajorflood,fire,orwarmayrequirethatacitybeevacuatedandrebuiltfromthegroundup.More
often,changetakesplaceabuildingorblockatatime,whilethecityasawholecontinuestofunction.
Onceestablished,astrategyofKEEPINGITWORKINGpreservesamunicipalitysvitalityasitgrows.
Systemsandtheirconstituentelementsevolveatdifferentrates.Astheydo,thingsthatchangequickly
tendtobecomedistinctfromthingsthatchangemoreslowly.TheSHEARINGLAYERSthatdevelop
betweenthemarelikefaultlinesorfacetsthathelpfostertheemergenceofenduringabstractions.
Asimplewaytobegintocontroldeclineistocordonofftheblightedareas,andputanattractivefaade
aroundthem.WecallthisstrategySWEEPINGITUNDERTHERUG.Inmoreadvancedcases,there
maybenoalternativebuttoteareverythingdownandstartover.WhentotalRECONSTRUCTION
becomesnecessary,allthatislefttosalvageisthepatternsthatunderlietheexperience.
http://www.laputan.org/mud/

3/36

1/6/2015

Big Ball of Mud

Someofthesepatternsmightappearatfirsttobeantipatterns[Brownetal.1998]orstrawmen,butthey
arenot,atleastinthecustomarysense.Instead,theyseektoexaminethegapbetweenwhatwepreach
andwhatwepractice.
Still,someofthemmaystrikesomereadersashavingaschizoidqualityaboutthem.So,fortherecord,
letusputourcardsonthetable.Weareinfavorofgoodarchitecture.
Ourultimateagendaistohelpdraintheseswamps.Wherepossible,architecturaldeclineshouldbe
prevented,arrested,orreversed.Wediscusswaysofdoingthis.Inseverecases,architectural
abominationsmayevenneedtobedemolished.
Atthesametime,weseeknottocastblameuponthosewhomustwallowinthesemires.Inpart,our
attitudeisto"hatethesin,butlovethesinner".But,itgoesbeyondthis.Noteverybackyardstorageshack
needsmarblecolumns.Therearesignificantforcesthatcanconspiretocompelarchitecturetotakeaback
seattofunctionality,particularlyearlyintheevolutionofasoftwareartifact.Opportunitiesandinsights
thatcanallowforarchitecturalprogressoftenarepresentlaterratherthanearlierinthelifecycle.
Acertainamountofcontrolledchaosisnaturalduringconstruction,andcanbetolerated,aslongasyou
cleanupafteryourselfeventually.Evenbeyondthisthough,acomplexsystemmaybeanaccurate
reflectionofourimmatureunderstandingofacomplexproblem.Theclassofsystemsthatwecanbuildat
allmaybelargerthantheclassofsystemswecanbuildelegantly,atleastatfirst.Asomewhat
ramshacklerat'snestmightbeastateoftheartarchitectureforapoorlyunderstooddomain.Thisshould
notbetheendofthestory,though.Aswegainmoreexperienceinsuchdomains,weshouldincreasingly
directourenergiestogleaningmoreenduringarchitecturalabstractionsfromthem.
Thepatternsdescribedhereinarenotintendedtostandalone.Theyareinsteadsetinacontextthat
includesanumberofotherpatternsthatweandothershavedescribed.Inparticular,theyaresetin
contrasttothelifecyclepatterns,PROTOTYPEPHASE,EXPANSIONARYPHASE,and
CONSOLIDATIONPHASE,presentedin[Foote&Opdyke1995]and[Coplien1995],theSOFTWARE
TECTONICSpatternin[Foote&Yoder1996],andtheframeworkdevelopmentpatternsin[Roberts&
Johnson1998].
Indeed,toasubstantialextent,muchofthischapterdescribesthedisease,whilethepatternsabove
describewhatwebelievecanbethecure:aflexible,adaptive,feedbackdrivendevelopmentprocessin
whichdesignandrefactoringpervadethelifecycleofeachartifact,component,andframework,within
andbeyondtheapplicationsthatincubatethem.

Forces
Anumberofforcescanconspiretodriveeventhemostarchitecturallyconscientiousorganizationsto
produceBIGBALLSOFMUD.Thesepervasive,"global"forcesareatworkinallthepatternspresented.
Amongtheseforces:
Time:Theremaynotbeenoughtimetoconsiderthelongtermarchitecturalimplicationsofonesdesign
andimplementationdecisions.Evenwhensystemshavebeenwelldesigned,architecturalconcernsoften
mustyieldtomorepragmaticonesasadeadlinestartstoloom.
Onereasonthatsoftwarearchitecturesaresooftenmediocreisthatarchitecturefrequentlytakesaback
seattomoremundaneconcernssuchascost,timetomarket,andprogrammerskill.Architectureisoften
seenasaluxuryorafrill,ortheindulgentpursuitoflilygildingcompulsiveswhohavenoconcernforthe
bottomline.Architectureisoftentreatedwithneglect,andevendisdain.Whilesuchattitudesare
unfortunate,theyarenothardtounderstand.Architectureisalongtermconcern.Theconcernsabove
havetobeaddressedifaproductisnottobestillborninthemarketplace,whilethebenefitsofgood
architecturearerealizedlaterinthelifecycle,asframeworksmature,andreusableblackboxcomponents
emerge[Foote&Opdyke1995].
http://www.laputan.org/mud/

4/36

1/6/2015

Big Ball of Mud

ArchitecturecanbelookeduponasaRisk,thatwillconsumeresourcesbetterdirectedatmeetinga
fleetingmarketwindow,orasanOpportunitytolaythegroundworkforacommandingadvantagedown
theroad.
Indeed,animmaturearchitecturecanbeanadvantageinagrowingsystembecausedataandfunctionality
canmigratetotheirnaturalplacesinthesystemunencumberedbyartificialarchitecturalconstraints.
Prematurearchitecturecanbemoredangerousthannoneatall,asunprovedarchitecturalhypothesesturn
intostraightjacketsthatdiscourageevolutionandexperimentation.
Cost:Architectureisexpensive,especiallywhenanewdomainisbeingexplored.Gettingthesystem
rightseemslikeapointlessluxuryoncethesystemislimpingwellenoughtoship.Aninvestmentin
architectureusuallydoesnotpayoffimmediately.Indeed,ifarchitecturalconcernsdelayaproducts
marketentryfortoolong,thenlongtermconcernsmaybemoot.Whobenefitsfromaninvestmentin
architecture,andwhenisareturnonthisinvestmentseen?Moneyspentonaquickanddirtyprojectthat
allowsanimmediateentryintothemarketmaybebetterspentthanmoneyspentonelaborate,speculative
architecturalfishingexpedition.Itshardtorecoverthevalueofyourarchitecturalassetsifyouvelong
sincegonebankrupt.
Programmerswiththeabilitytodiscernanddesignqualityarchitecturesarereputedtocommanda
premium.Theseexpensesmustbeweighedagainstthoseofallowinganexpensivesystemtoslipinto
prematuredeclineandobsolescence.Ifyouthinkgoodarchitectureisexpensive,trybadarchitecture.
Experience:Evenwhenonehasthetimeandinclinationtotakearchitecturalconcernsintoaccount,ones
experience,orlackthereof,withthedomaincanlimitthedegreeofarchitecturalsophisticationthatcanbe
broughttoasystem,particularlyearlyinitsevolution.Someprogrammersflourishinenvironments
wheretheycandiscoveranddevelopnewabstractions,whileothersaremorecomfortableinmore
constrainedenvironments(forinstance,Smalltalkvs.VisualBasicprogrammers.)Often,initialversions
ofasystemarevehicleswherebyprogrammerslearnwhatpiecesmustbebroughtintoplaytosolvea
particularproblem.Onlyaftertheseareidentifieddothearchitecturalboundariesamongpartsofthe
systemstarttoemerge.
Inexperiencecantakeanumberofguises.Thereisabsolute,freshoutofschoolinexperience.Agood
architectmaylackdomainexperience,oradomainexpertwhoknowsthecodecoldmaynothave
architecturalexperience.
Employeeturnovercanwreakhavoconanorganizationsinstitutionalmemory,withtheperhapsdubious
consolationofbringingfreshbloodaboard.
Skill:Programmersdifferintheirlevelsofskill,aswellasinexpertise,predispositionandtemperament.
Someprogrammershaveapassionforfindinggoodabstractions,whilesomeareskilledatnavigatingthe
swampsofcomplexcodelefttothembyothers.Programmersdiffertremendouslyintheirdegreesof
experiencewithparticulardomains,andtheircapacitiesforadaptingtonewones.Programmersdifferin
theirlanguageandtoolpreferencesandexperienceaswell.
Visibility:Buildingsaretangible,physicalstructures.Youcanlookatabuilding.Youcanwatchitbeing
built.Youcanwalkinsideit,andadmireandcritiqueitsdesign.
Aprogramsuserinterfacepresentsthepublicfaceofaprogram,muchasabuildingsexteriormanifests
itsarchitecture.However,unlikebuildings,onlythepeoplewhobuildaprogramseehowitlooksinside.
Programsaremadeofbits.Themannerinwhichwepresentthesebitsgreatlyaffectsoursenseofhow
theyareputtogether.Somedesignersprefertoseesystemsdepictedusingmodelinglanguagesor
PowerPointpictures.Otherspreferprosedescriptions.Stillothersprefertoseecode.Thefashioninwhich
wepresentourarchitecturesaffectsourperceptionsofwhethertheyaregoodorbad,clearormuddled,
andelegantormuddy.
http://www.laputan.org/mud/

5/36

1/6/2015

Big Ball of Mud

Indeed,oneofthereasonsthatarchitectureisneglectedisthatmuchofitis"underthehood",where
nobodycanseeit.Ifthesystemworks,anditcanbeshipped,whocareswhatitlookslikeontheinside?
Complexity:Onereasonforamuddledarchitectureisthatsoftwareoftenreflectstheinherentcomplexity
oftheapplicationdomain.ThisiswhatBrookscalled"essentialcomplexity"[Brooks1995].Inother
words,thesoftwareisuglybecausetheproblemisugly,oratleastnotwellunderstood.Frequently,the
organizationofthesystemreflectsthesprawlandhistoryoftheorganizationthatbuiltit(asper
CONWAYSLAW[Coplien1995])andthecompromisesthatweremadealongtheway.Renegotiating
theserelationshipsisoftendifficultoncethebasicboundariesamongsystemelementsaredrawn.These
relationshipscantakeontheimmutablecharacterof"site"boundariesthatBrand[Brand1994]observed
inrealcities.Bigproblemscanariseswhentheneedsoftheapplicationsforceunrestrained
communicationacrosstheseboundaries.Thesystembecomesatangledmess,andwhatlittlestructureis
therecanerodefurther.
Change:Architectureisahypothesisaboutthefuturethatholdsthatsubsequentchangewillbeconfined
tothatpartofthedesignspaceencompassedbythatarchitecture.Ofcourse,theworldhasawayof
mockingourattemptstomakesuchpredictionsbytossingusthetotallyunexpected.Aproblemwemight
havebeentoldwasdefinitelyruledoutofconsiderationforalltimemayturnouttobedeartotheheartof
anewclientweneverthoughtwedhave.Suchchangesmaycutdirectlyacrossthegrainoffundamental
architecturaldecisionsmadeinthelightofthecertaintythatthesenewcontingenciescouldneverarise.
The"right"thingtodomightbetoredesignthesystem.Themorelikelyresultisthatthearchitectureof
thesystemwillbeexpedientlyperturbedtoaddressthenewrequirements,withonlypassingregardfor
theeffectoftheseradicalchangesonthestructureofthesystem.
Scale:Managingalargeprojectisaqualitativelydifferentproblemfrommanagingasmallone,justas
leadingadivisionofinfantryintobattleisdifferentfromcommandingasmallspecialforcesteam.
Obviously,"divideandconquer"is,ingeneral,aninsufficientanswertotheproblemsposedbyscale.
AlanKay,duringaninvitedtalkatOOPSLA'86observedthat"goodideasdon'talwaysscale."That
observationpromptedHenryLiebermantoinquire"sowhatdowedo,justscalethebadones?"

BIGBALLOFMUD
alias
SHANTYTOWN
SPAGHETTICODE

Shantytownsaresqualid,sprawlingslums.Everyoneseemstoagreetheyareabadidea,butforces
http://www.laputan.org/mud/

6/36

1/6/2015

Big Ball of Mud

conspiretopromotetheiremergenceanyway.Whatisitthattheyaredoingright?
Shantytownsareusuallybuiltfromcommon,inexpensivematerialsandsimpletools.Shantytownscanbe
builtusingrelativelyunskilledlabor.Eventhoughthelaborforceis"unskilled"inthecustomarysense,
theconstructionandmaintenanceofthissortofhousingcanbequitelaborintensive.Thereislittle
specialization.Eachhousingunitisconstructedandmaintainedprimarilybyitsinhabitants,andeach
inhabitantmustbeajackofallthenecessarytrades.Thereislittleconcernforinfrastructure,since
infrastructurerequirescoordinationandcapital,andspecializedresources,equipment,andskills.Thereis
littleoverallplanningorregulationofgrowth.Shantytownsemergewherethereisaneedforhousing,a
surplusofunskilledlabor,andadearthofcapitalinvestment.Shantytownsfulfillanimmediate,local
needforhousingbybringingavailableresourcestobearontheproblem.Loftierarchitecturalgoalsarea
luxurythathastowait.
Maintainingashantytownislaborintensiveandrequiresabroadrangeofskills.Onemustbeableto
improviserepairswiththematerialsonhand,andmastertasksfromroofrepairtoadhocsanitation.
However,thereislittleofthesortofskilledspecializationthatoneseesinamatureeconomy.
Alltoomanyofoursoftwaresystemsare,architecturally,littlemorethanshantytowns.Investmentin
toolsandinfrastructureistooofteninadequate.Toolsareusuallyprimitive,andinfrastructuresuchas
librariesandframeworks,isundercapitalized.Individualportionsofthesystemgrowunchecked,andthe
lackofinfrastructureandarchitectureallowsproblemsinonepartofthesystemtoerodeandpollute
adjacentportions.Deadlinesloomlikemonsoons,andarchitecturaleleganceseemsunattainable.
vvv
Asasystemnearscompletion,itsactualusersmaybegintoworkwithitforthefirsttime.This
experiencemayinspirechangestodataformatsandtheuserinterfacethatunderminearchitectural
decisionsthathadbeenthoughttobesettled.Also,asBrooks[Brooks1995]hasnoted,becausesoftware
issoflexible,itisoftenaskedtobeartheburdenofarchitecturalcompromiseslateinthedevelopment
cycleofhardware/softwaredeliverablespreciselybecauseofitsflexibility.
Thisphenomenonisnotuniquetosoftware.StewartBrand[Brand1994]hasobservedthattheperiodjust
priortoabuildingsinitialoccupancycanbeastressfulperiodforbotharchitectsandtheirclients.The
moneyisrunningout,andthefinishingtouchesarebeingputonjustthosepartsofthespacethatwill
interactthemostwithitsoccupants.Duringthisperiod,itcanbecomeevidentthatcertainwishlistitems
arenotgoingtomakeit,andthatexoticexperimentsarenotgoingtowork.Compromisebecomesthe
"orderoftheday".
Thetimeandmoneytochaseperfectionareseldomavailable,norshouldtheybe.Tosurvive,wemustdo
whatittakestogetoursoftwareworkingandoutthedoorontime.Indeed,ifateamcompletesaproject
withtimetospare,todaysmanagersarelikelytotakethatasasigntoprovidelesstimeandmoneyor
fewerpeoplethenexttimearound.
Youneedtodeliverqualitysoftwareontime,andunderbudget.
Cost:Architectureisalongterminvestment.Itiseasyforthepeoplewhoarepayingthebillstodismiss
it,unlessthereissometangibleimmediatebenefit,suchataxwriteoff,orunlesssurplusmoneyandtime
happenstobeavailable.Suchisseldomthecase.Moreoften,thecustomerneedssomethingworkingby
tomorrow.Often,thepeoplewhocontrolandmanagethedevelopmentprocesssimplydonotregard
architectureasapressingconcern.Ifprogrammersknowthatworkmanshipisinvisible,andmanagers
don'twanttopayforitanyway,aviciouscircleisborn.
Skill:RalphJohnsonisfondofobservingthatisinevitablethat"onaverage,averageorganizationswill
haveaveragepeople".OnereasonforthepopularityandsuccessofBIGBALLOFMUDapproaches
mightbethatthisappoachdoesn'trequireahyperproductivevirtuosoarchitectateverykeyboard.
Organization:Withlargerprojects,cultural,process,organizationalandresourceallocationissuescan
http://www.laputan.org/mud/

7/36

1/6/2015

Big Ball of Mud

overwhelmtechnicalconcernssuchastools,languages,andarchitecture.
Itmayseemtoaprogrammerthatwhethertodonhipbootsandwadeintoaswampisamajorqualityof
lifematter,butprogrammercomfortisbutoneconcerntoamanager,whichcanconflictwithmany
others.Architectureandcodequalitymaystrikemanagementasfrillsthathaveonlyanindirectimpacton
theirbottomlines.
Therefore,focusfirstonfeaturesandfunctionality,thenfocusonarchitectureandperformance.
ThecasemadehereresemblesGabriels"WorseisBetter"arguments[Gabriel1991]inanumberof
respects.Whydoessomuchsoftware,despitethebestintentionsandeffortsofdevelopers,turnintoBIG
BALLSOFMUD?Whydoslashandburntacticsdriveoutelegance?Doesbadarchitecturedriveout
goodarchitecture?
Whatdoesthismuddycodelookliketotheprogrammersinthetrencheswhomustconfrontit?Data
structuresmaybehaphazardlyconstructed,orevennexttononexistent.Everythingtalkstoeverything
else.Everyshredofimportantstatedatamaybeglobal.Therearethosewhomightconstruethisasasort
ofblackboardapproach[Buschmann1996],butitmorecloselyresemblesagrabbagofundifferentiated
state.Wherestateinformationiscompartmentalized,itmaybepassedpromiscuouslyaboutthough
Byzantinebackchannelsthatcircumventthesystem'soriginalstructure.
Variableandfunctionnamesmightbeuninformative,orevenmisleading.Functionsthemselvesmay
makeextensiveuseofglobalvariables,aswellaslonglistsofpoorlydefinedparameters.Thefunction
themselvesarelengthyandconvoluted,andperformseveralunrelatedtasks.Codeisduplicated.Theflow
ofcontrolishardtounderstand,anddifficulttofollow.Theprogrammersintentisnexttoimpossibleto
discern.Thecodeissimplyunreadable,andbordersonindecipherable.Thecodeexhibitsthe
unmistakablesignsofpatchafterpatchatthehandsofmultiplemaintainers,eachofwhombarely
understoodtheconsequencesofwhatheorshewasdoing.Didwementiondocumentation?What
documentation?
BIGBALLOFMUDmightbethoughtofasanantipattern,sinceourintentionistoshowhowpassivity
inthefaceofforcesthatunderminearchitecturecanleadtoaquagmire.However,itsundeniable
popularityleadstotheinexorableconclusionthatitisapatterninitsownright.Itiscertainlyapervasive,
recurringsolutiontotheproblemofproducingaworkingsysteminthecontextofsoftwaredevelopment.
Itwouldseemtobethepathofleastresistancewhenoneconfrontsthesortsofforcesdiscussedabove.
OnlybyunderstandingthelogicofitsappealcanwechannelorcounteracttheforcesthatleadtoaBIG
BALLOFMUD.
Onethingthatisnttheanswerisrigid,totalitarian,topdowndesign.Someanalysts,designers,and
architectshaveanexaggeratedsenseoftheirabilitytogetthingsrightupfront,beforemovinginto
implementation.Thisapproachleadstoinefficientresourcesutilization,analysisparalysis,anddesign
straightjacketsandculdesacs.
KentBeckhasobservedthatthewaytobuildsoftwareisto:Makeitwork.Makeitright.Makeitfast
[Beck1997]."Makeitwork"meansthatweshouldfocusonfunctionalityupfront,andgetsomething
running."Makeitright"meansthatweshouldconcernourselveswithhowtostructurethesystemonly
afterwevefiguredoutthepiecesweneedtosolvetheprobleminthefirstplace."Makeitfast"means
thatweshouldbeconcernedaboutoptimizingperformanceonlyafterwevelearnedhowtosolvethe
problem,andafterwevediscernedanarchitecturetoelegantlyencompassthisfunctionality.Onceallthis
hasbeendone,onecanconsiderhowtomakeitcheap.
Whenitcomestosoftwarearchitecture,formfollowsfunction.Herewemean"follows"notinthe
traditionalsenseofdictatingfunction.Instead,wemeanthatthedistinctidentitiesofthesystems
architecturalelementsoftendontstarttoemergeuntilafterthecodeisworking.
Domainexperienceisanessentialingredientinanyframeworkdesigneffort.Itishardtotrytofollowa
frontloaded,topdowndesignprocessunderthebestofcircumstances.Withoutknowingthearchitectural
http://www.laputan.org/mud/

8/36

1/6/2015

Big Ball of Mud

demandsofthedomain,suchanattemptispremature,ifnotfoolhardy.Often,theonlywaytogetdomain
experienceearlyinthelifecycleistohiresomeonewhohasworkedinadomainbeforefromsomeone
else.
Thequalityofonestoolscaninfluenceasystemsarchitecture.Ifasystemsarchitecturalgoalsare
inadequatelycommunicatedamongmembersofateam,theywillbehardertotakeintoaccountasthe
systemisdesignedandconstructed.
Finally,engineerswilldifferintheirlevelsofskillandcommitmenttoarchitecture.Sadly,architecture
hasbeenundervaluedforsolongthatmanyengineersregardlifewithaBIGBALLOFMUDasnormal.
Indeedsomeengineersareparticularlyskilledatlearningtonavigatethesequagmires,andguidingothers
throughthem.Overtime,thissymbiosisbetweenarchitectureandskillscanchangethecharacterofthe
organizationitself,asswampguidesbecomemorevaluablethanarchitects.AsperCONWAYSLAW
[Coplien1995],architectsdepartinfutility,whileengineerswhohavemasteredthemuddydetailsofthe
systemtheyhavebuiltintheirimagesprevail.[Foote&Yoder1998a]wentsofarastoobservethat
inscrutablecodemight,infact,haveasurvivaladvantageovergoodcode,byvirtueofbeingdifficultto
comprehendandchange.Thisadvantagecanextendtothoseprogrammerswhocanfindtheirways
aroundsuchcode.Inalanddevoidoflandmarks,suchguidesmaybecomeindispensable.
Theincentivesthatdrivetheevolutionofsuchsystemscan,attimes,operateperversely.Justasitis
easiertobeverbosethanconcise,itiseasiertobuildcomplexsystemsthanitistobuildsimpleones.
Skilledprogrammersmaybeabletocreatecomplexitymorequicklythantheirpeers,andmorequickly
thantheycandocumentandexplainit.Likeanarmyoutrunningitslogisticstrain,complexityincreases
untilitreachesthepointwheresuchprogrammerscannolongerreliablycopewithit.
ThisisakintoaphenonmenondubbedthePeterPrincipleofProgrammingbyauthorsontheWikiWiki
web[Cunninghan1999a].Complexityincreasesrapidlyuntiltheitreachesalevelofcomplexityjust
beyondthatwithwhichprogrammerscancomfortablycope.Atthispoint,complexityandourabilitiesto
containitreachanuneasyequilibrium.Theblitzkriegbogsdownintoasiege.Webuiltthemost
complicatedsystemthatcanpossiblework[Cunningham1999b].
Suchcodecanbecomeapersonalfiefdom,sincetheauthor
carebarelyunderstanditanymore,andnooneelsecan
comeclose.Oncesimplerepairsbecomealldayaffairs,as
thecodeturnstomud.Itbecomesincreasinglydifficultfor
managementtotellhowlongsuchrepairsoughttotake.
Simpleobjectivesturnintotrenchwarfare.Everyone
becomesresignedtoaturgidpace.Someevencometo
preferit,hidingintheircozyfoxholes,andmakingtheir
twolineperdayrepairs.
Itisinterestingtoaskwhethersomeofthedifferencesin
productivityseenbetweenhyperproductiveorganizations
andtypicalshopsareduenottodifferencesintalent,but
differencesinterrain.Mudishardtomarchthrough.The
hackerinthetrenchesmustengagecomplexityinhandto
handcombateveryday.Sometimes,complexitywins.
Statusintheprogrammer'sprimatepeckingorderisoften
earnedthroughritualdisplaysofcleverness,ratherthan
throughworkmanlikedisplaysofsimplicityandclarity.
Thatwhichacultureglorifieswillflourish.
Yet,acasecanbemadethatthecasual,undifferentiatedstructureofaBIGBALLOFMUDisoneofits
secretadvantages,sinceforcesactingbetweentwopartsofthesystemcanbedirectlyaddressedwithout
havingtoworryaboutunderminingthesystemsgranderarchitecturalaspirations.Theseaspirationsare
modestonesatbestinthetypicalBIGBALLOFMUD.Indeed,acasualapproachtoarchitectureis
http://www.laputan.org/mud/

9/36

1/6/2015

Big Ball of Mud

emblematicoftheearlyphasesofasystemsevolution,asprogrammers,architectsanduserslearntheir
wayaroundthedomain[Foote&Opdyke1995].DuringthePROTOTYPEandEXPANSIONARY
PHASESofasystemsevolution,expedient,whiteboxinheritancebasedcodeborrowing,andarelaxed
approachtoencapsulationarecommon.Later,asexperiencewiththesystemaccrues,thegrainofthe
architecturaldomainbecomesdiscernable,andmoredurableblackboxcomponentsbegintoemerge.In
otherwords,itsokayifthesystemlooksatfirstlikeaBIGBALLOFMUD,atleastuntilyouknow
better.

vvv
BrianMarickfirstsuggestedthename"BIGBALLOFMUD"asanameforthesesortofarchitectures,
andtheobservationthatthiswas,perhaps,thedominantarchitecturecurrentlydeployed,duringameeting
oftheUniversityofIllinoisSoftwareArchitectureGroupseveralyearsago.Wehavebeenusingtheterm
eversince.Thetermitself,inturn,appearstohavearisenduringthe'70sasacharacterizationofLisp.
BIGBALLOFMUDarchitecturesoftenemergefromthrowawayprototypes,orTHROWAWAY
CODE,becausetheprototypeiskept,orthedisposablecodeisneverdisposedof.(Onemightcallthese
"littleballsofmud".)
TheyalsocanemergeasgradualmaintenanceandPIECEMEALGROWTHimpingesuponthestructure
ofamaturesystem.Onceasystemisworking,agoodwaytoencourageitsgrowthistoKEEPIT
WORKING.WhentheSHEARINGLAYERSthatemergeaschangedrivesthesystem'sevolutionrun
againsttheexistinggrainofthesystem,itsstructurecanbeundermined,andtheresultcanbeaBIG
BALLOFMUD.
ThePROTOTYPEPHASEandEXPANSIONPHASEpatternsin[Foote&Opdyke1995]both
emphasizethataperiodofexplorationandexperimentationisoftenbeneficialbeforemakingenduring
architecturalcommitments.
However,theseactivities,whichcanundermineasystem'sstructureshouldbeinterspersedwith
CONSOLIDATIONPHASES[Foote&Opdyke1995],duringwhichopportunitiestorefactorthesystem
toenhanceitsstructureareexploited.ProponentsofExtremeProgramming[Beck2000]alsoemphasize
continuouscodingandrefactoring.
[Brand1994]observesthatbuildingswithlargespacespunctuatedwithregularcolumnshadthe
http://www.laputan.org/mud/

10/36

1/6/2015

Big Ball of Mud

paradoxicaleffectofencouragingtheinnovativereuseofspacepreciselybecausetheyconstrainedthe
designspace.Grandioseflightsofarchitecturalfancywerentpossible,whichreducedthenumberof
designalternativesthatcouldbeputonthetable.SometimesFREEDOMFROMCHOICE[Foote1988]
iswhatwereallywant.
Oneofmud'smosteffectiveenemiesissunshine.Subjectingconvolutedcodetoscrutinycansetthestage
foritsrefactoring,repair,andrehabilitation.Codereviewsareonemechanismonecanusetoexposecode
todaylight.
AnotheristheExtremeProgrammingpracticeofpairprogramming[Beck2000].Apurepair
programmingapproachrequiresthateverylineofcodewrittenbeaddedtothesystemwithtwo
programmerspresent.Onetypes,or"drives",whiletheother"ridesshotgun"andlookson.Incontrastto
traditionalsolitarysoftwareproductionpractices,pairprogrammingsubjectscodetoimmediatescrutiny,
andprovidesameansbywhichknowledgeaboutthesystemisrapidlydisseminated.
Indeed,reviewsandpairprogrammingprovideprogrammerswithsomethingtheirworkwouldnot
otherwisehave:anaudience.Sunlight,itissaidisapowerfuldisinfectant.Pairpracticesaddanelement
ofperformancetoprogramming.Animmediateaudienceofone'speersprovidesimmediateincentivesto
programmerstokeeptheircodeclearandcomprehensible,aswellasfunctional.
Anadditionalbenefitofpairingisthataccumulatedwisdomandbestpracticescanberapidly
disseminatedthroughoutanorganizationthroughsuccessivepairings.Thisis,incidentally,thesame
benefitthatsexualreproductionbroughttothegenome.
Bycontrast,ifnooneeverlooksatcode,everyoneisfreetothinktheyarebetterthanaverageat
producingit.Programmerswill,instead,respondtothoserelativelyperverseincentivesthatdoexist.Line
ofcodemetrics,designdocuments,andotherindirectmeasurementsofprogressandqualitycanbecome
centralconcerns.
TherearethreewaystodealwithBIGBALLSOFMUD.Thefirstistokeepthesystemhealthy.
ConscientiouslyalternatingperiodsofEXPANSIONwithperiodsofCONSOLIDATION,refactoringand
repaircanmaintain,andevenenhanceasystem'sstructureasitevolves.Thesecondistothrowthe
systemawayandstartover.TheRECONSTRUCTIONpatternexploresthisdrastic,butfrequently
necessaryalternative.Thethirdistosimplysurrendertoentropy,andwallowinthemire.
SincethetimeofRomanarchitectMarcusVitruvius,[Vitruvius20B.C.]architectshavefocusedonhis
trinityofdesirables:Firmitas(strength),Utilitas(utility),andVenustas(beauty).ABIGBALLOF
MUDusuallyrepresentsatriumphofutilityoveraesthetics,becauseworkmanshipissacrificedfor
functionality.Structureanddurabilitycanbesacrificedaswell,becauseanincomprehensibleprogram
defiesattemptsatmaintenance.Thefrenzied,featuredriven"bloatware"phenomenonseeninmanylarge
consumersoftwareproductscanbeseenasevidenceofdesignershavingallowedpurelyutilitarian
concernstodominatesoftwaredesign.

THROWAWAYCODE
alias
QUICKHACK
KLEENEXCODE
DISPOSABLECODE
SCRIPTING
KILLERDEMO
PERMANENTPROTOTYPE
BOOMTOWN
http://www.laputan.org/mud/

11/36

1/6/2015

Big Ball of Mud

vvv
Ahomeownermighterectatemporarystorageshedorcarport,witheveryintentionofquicklytearingit
downandreplacingitwithsomethingmorepermanent.Suchstructureshaveawayofenduring
indefinitely.Themoneyexpectedtoreplacethemmightnotbecomeavailable.Or,oncethenewstructure
isconstructed,thetemptationtocontinuetousetheoldonefor"awhile"mightbehardtoresist.
Likewise,whenyouareprototypingasystem,youarenotusuallyconcernedwithhowelegantorefficient
yourcodeis.Youknowthatyouwillonlyuseittoproveaconcept.Oncetheprototypeisdone,thecode
willbethrownawayandwrittenproperly.Asthetimenearstodemonstratetheprototype,thetemptation
toloaditwithimpressivebututterlyinefficientrealizationsofthesystemsexpectedeventual
functionalitycanbehardtoresist.Sometimes,thisstrategycanbeabittoosuccessful.Theclient,rather
thanfundingthenextphaseoftheproject,mayslatetheprototypeitselfforrelease.
Youneedanimmediatefixforasmallproblem,oraquickprototypeorproofofconcept.
Time,oralackthereof,isfrequentlythedecisiveforcethatdrivesprogrammerstowriteTHROWAWAY
CODE.Takingthetimetowriteaproper,wellthoughtout,welldocumentedprogrammighttakemore
timethatisavailabletosolveaproblem,ormoretimethattheproblemmerits.Often,theprogrammer
willmakeafranticdashtoconstructaminimallyfunctionalprogram,whileallthewhilepromisinghim
orherselfthatabetterfactored,moreelegantversionwillfollowthereafter.Theymayknowfullwellthat
buildingareusablesystemwillmakeiteasiertosolvesimilarproblemsinthefuture,andthatamore
polishedarchitecturewouldresultinasystemthatwaseasiertomaintainandextend.
Quickanddirtycodingisoftenrationalizedasbeingastopgapmeasure.Alltoooften,timeisnever
foundforthisfollowupwork.Thecodelanguishes,whiletheprogramflourishes.
Therefore,produce,byanymeansavailable,simple,expedient,disposablecodethatadequately
addressesjusttheproblemathand.
THROWAWAYCODEisoftenwrittenasanalternativetoreusingsomeoneelsesmorecomplexcode.
Whenthedeadlinelooms,thecertaintythatyoucanproduceasloppyprogramthatworksyourselfcan
outweightheunknowncostoflearningandmasteringsomeoneelseslibraryorframework.
http://www.laputan.org/mud/

12/36

1/6/2015

Big Ball of Mud

Programmersareusuallynotdomainexperts,especiallyatfirst.UsecasesorCRCcards[Beck&
Cunningham1989]canhelpthemtodiscoverdomainobjects.However,nothingbeatsbuildinga
prototypetohelpateamlearnitswayaroundadomain.
Whenyoubuildaprototype,thereisalwaystheriskthatsomeonewillsay"that'sgoodenough,shipit".
Onewaytominimizetheriskofaprototypebeingputintoproductionistowritetheprototypeinusinga
languageortoolthatyoucouldn'tpossiblyuseforaproductionversionofyourproduct.Proponentsof
ExtremeProgramming[Beck2000]oftenconstructquick,disposableprototypescalled"spikesolutions".
Prototypeshelpuslearnourwayaroundtheproblemspace,butshouldneverbemistakenforgood
designs[Johnson&Foote1988].
Noteveryprogramneedbeapalace.Asimplethrowawayprogramislikeatentcityoramining
boomtown,andoftenhasnoneedforfiftyyearsolutionstoitsproblems,giventhatitwillgivewaytoa
ghosttowninfive.
Therealproblemwith
THROWAWAYCODEcomeswhenitisn'tthrownaway.
vvv
TheproductionofTHROWAWAYCODEisanearlyuniversalpractice.Anysoftwaredeveloper,atany
skillorexperiencelevel,canbeexpectedtohavehadatleastoccasionalfirsthandexperiencewiththis
approachtosoftwaredevelopment.Forexample,inthepatternscommunity,twoexamplesofquickand
dirtycodethathaveenduredarethePLoPonlineregistrationcode,andtheWikiWikiWebpages.
TheEuroPLoP/PLoP/UPonlineregistrationcodewas,ineffect,adistributedwebbasedapplicationthat
ranonfourdifferentmachinesontwocontinents.Conferenceinformationwasmaintainedonamachine
inSt.Louis,whileregistrationrecordswerekeptonmachinesinIllinoisandGermany.Thesystemcould
generatewebbasedreportsofregistrationactivity,andnoweveninstantaneouslymaintaineedanonline
attendeeslist.Itbeganlifein1995asaquickanddirtycollectionofHTML,scavengedCdemonstration
code,andcshscripts.Itwasundertakenlargelyasanexperimentinwebbasedformprocessingpriorto
PLoP95,and,likesomanythingsontheWeb,succeededconsiderablybeyondtheexpectationsofits
authors.Today,itisstillessentiallythesamecollectionofHTML,scavengedCdemonstrationcode,and
cshscripts.Assuch,itshowcaseshowquickanddirtycodecan,whensuccessful,takeonalifeofits
own.
TheoriginalCcodeandscriptsprobablycontainedfewerthanthreedozenoriginallinesofcode.Many
lineswerecutandpastejobsthatdifferedonlyinthespecifictexttheygenerate,orfieldsthattheycheck.
Heresanexampleofoneofthescriptsthatgeneratestheattendancereport:
echo"<H2>Registrations:<B>"`ls|wcl`"</B></H2>"
echo"<CODE>"
echo"Authors:<B>"`grep'Author=Yes'*|wcl`"</B>"
echo"<BR>"
echo"NonAuthors:<B>"`grep'Author=No'*|wcl`"</B>"
echo"<BR><BR>"

Thisscriptisslowandinefficient,particularlyasthenumberofregistrationsincreases,butnotleast
amongitsvirtuesisthefactthatitworks.Werethenumberofattendeestoexceedmorethanaroundone
hundred,thisscriptwouldstarttoperformsobadlyastobeunusable.However,sincehundredsof
attendeeswouldexceedthephysicalcapacityoftheconferencesite,weknewthenumberofregistrations
wouldhavebeenlimitedlongbeforetheperformanceofthisscriptbecameasignificantproblem.So
whilethisapproachis,ingeneral,alousywaytoaddressthisproblem,itisperfectlysatisfactorywithin
theconfinesoftheparticularpurposeforwhichthescripthaseveractuallybeenused.Suchpractical
constraintsaretypicalofTHROWAWAYCODE,andaremoreoftenthannotundocumented.Forthat
http://www.laputan.org/mud/

13/36

1/6/2015

Big Ball of Mud

matter,everythingaboutTHROWAWAYCODEismoreoftenthannotundocumented.When
documentationexists,itisfrequentlynotcurrent,andoftennotaccurate.
TheWikiWebcodeatwww.c2.comalsostartedasaCGIexperimentundertakenbyWardCunningham
alsosucceededbeyondtheauthorsexpectations.Thename"wiki"isoneofWardspersonaljokes,
havingbeentakenfromaHawaiianwordfor"quick"thattheauthorhadseenonanairportvanona
vacationinHawaii.Wardhassubsequentlyusedthenameforanumberofquickanddirtyprojects.The
WikiWebisunusualinthatanyvisitormaychangeanythingthatanyoneelsehaswritten
indiscriminately.Thiswouldseemlikearecipeforvandalism,butinpractice,ithasworkedoutwell.In
lightofthesystemssuccess,theauthorhassubsequentlyundertakenadditionalworktopolishitup,but
thesamequickanddirtyPerlCGIcoreremainsattheheartofthesystem.
BothsystemsmightbethoughtofasbeingonthevergeofgraduatingfromlittleballsofmudtoBIG
BALLSOFMUD.TheregistrationsystemsCcodemetastasizedfromoneoftheNCSAHTTPDserver
demos,andstillcontainszombiecodethattestifiestothisheritage.Ateachstep,KEEPINGIT
WORKINGisapremiereconsiderationindecidingwhethertoextendorenhancethesystem.Both
systemsmightbegoodcandidatesforRECONSTRUCTION,weretheresources,interest,andaudience
presenttojustifysuchanundertaking.Inthemeantime,thesesystems,whicharestillsufficientlywell
suitedtotheparticulartasksforwhichtheywerebuilt,remaininservice.Keepingthemontheairtakes
farlessenergythanrewritingthem.Theycontinuetoevolve,inaPIECEMEALfashion,alittleatatime.
Youcanameloriatethearchitecturalerosionthatcanbecausedbyquickanddirtycodebyisolatingit
fromotherpartsofyoursystem,initsownobjects,packages,ormodules.Totheextentthatsuchcode
canbequarantined,itsabilitytoaffecttheintegrityofhealthypartsofasystemisreduced.
Onceitbecomesevidentthatapurportedlydisposableartifactisgoingtobearoundforawhile,onecan
turnone'sattentiontoimprovingitsstructure,eitherthroughaniterativeprocessofPIECEMEAL
GROWTH,orviaafreshdraft,asdiscussedintheRECONSTRUCTIONpattern.

Fromboomtowntoghosttown:
TheminingtownofRhyolite,inDeathValley,wasbrieflythethirdlargestcityin
Nevada.
Thentheoreranout.

PIECEMEALGROWTH
alias
URBANSPRAWL
http://www.laputan.org/mud/

14/36

1/6/2015

Big Ball of Mud

ITERATIVEINCREMENTALDEVELOPMENT

TheRussianMir("Peace")SpaceStationComplexwasdesignedforreconfigurationand
modulargrowth.TheCoremodulewaslaunchedin1986,andtheKvant("Quantum")and
Kvant2modulesjoinedthecomplexin1987and1989.TheKristall("Crystal")module
wasaddedin1990.TheSpektr("Spectrum")andshuttleDockingmoduleswereaddedin
1995,thelattersurelyadevelopmentnotanticipatedin1986.Thestationsfinal
module,Priroda("Nature"),waslaunchedin1996.Thecommoncoreandindependent
maneuveringcapabilitiesofseveralofthemoduleshaveallowedthecomplextobe
rearrangedseveraltimesasithasgrown.

Urbanplanninghasanunevenhistoryofsuccess.
Forinstance,WashingtonD.C.waslaidout
accordingtoamasterplandesignedbytheFrench
architectLEnfant.ThecapitalsofBrazil(Brasilia)
andNigeria(Abuja)startedaspapercitiesaswell.
Othercities,suchasHouston,havegrownwithout
anyoverarchingplantoguidethem.Eachapproach
hasitsproblems.Forinstance,theradialstreet
plansinLEnftantsmasterplanbecomeawkward
pastacertaindistancefromthecenter.Thelackof
anyplanatall,ontheotherhand,leadstoa
patchworkofresidential,commercial,and
industrialareasthatisdictatedbythecapricious
interactionoflocalforcessuchaslandownership,
capital,andzoning.Sinceconcernssuchasrecreation,shoppingclosetohomes,andnoiseandpollution
awayfromhomesarenotbroughtdirectlyintothemix,theyarenotadequatelyaddressed.
MostcitiesaremorelikeHoustonthanAbuja.Theymaybeginassettlements,subdivisions,docks,or
railwaystops.Maybepeopleweredrawnbygold,orlumber,accesstotransportation,oremptyland.As
timegoeson,certainsettlementsachieveacriticalmass,andapositivefeedbackcycleensues.Thecitys
successdrawstradesmen,merchants,doctors,andclergymen.Thegrowingpopulationisabletosupport
infrastructure,governmentalinstitutions,andpoliceprotection.These,inturn,drawmorepeople.
Differentsectionsoftowndevelopdistinctidentities.Withfewexceptions,(SaltLakeCitycomesto
mind)thefoundersofthesesettlementsneverstoppedtothinkthattheywerefoundingmajorcities.Their
ambitionswereusuallymoremodest,andimmediate.

http://www.laputan.org/mud/

15/36

1/6/2015

Big Ball of Mud

vvv
Ithasbecomefashionableoverthelastseveralyearstotakepotshotsatthe"traditional"waterfallprocess
model.Itmayseemtothereaderthatattackingitistantamounttofloggingadeadhorse.However,ifitbe
adeadhorse,itisatenaciousone.Whiletheapproachitselfisseenbymanyashavingbeenlongsince
discredited,ithasspawnedalegacyofrigid,topdown,frontloadedprocessesandmethodologiesthat
endure,invariousguises,tothisday.Wecandoworsethatexaminetheforcesthatledtoitsoriginal
development.
Inthedaysbeforewaterfalldevelopment,programmingpioneersemployedasimple,casual,relatively
undisciplined"codeandfix"approachtosoftwaredevelopment.Giventheprimitivenatureofthe
problemsoftheday,thisapproachwasfrequentlyeffective.However,theresultofthislackofdiscipline
was,alltoooften,aBIGBALLOFMUD.
Thewaterfallapproacharoseinresponsetothismuddymorass.Whilethecodeandfixapproachmight
havebeensuitableforsmalljobs,itdidnotscalewell.Assoftwarebecamemorecomplex,itwouldnot
dotosimplygatheraroomfullofprogrammerstogetherandtellthemtogoforthandcode.Larger
projectsdemandedbetterplanningandcoordination.Why,itwasasked,can'tsoftwarebeengineeredlike
carsandbridges,withacarefulanalysisoftheproblem,andadetailedupfrontdesignpriorto
implementation?Indeed,anexaminationofsoftwaredevelopmentcostsshowedthatproblemsweremany
timesmoreexpensivetofixduringmaintenancethanduringdesign.Surelyitwasbesttomobilize
resourcesandtalentupfront,soastoavoidmaintenanceexpensesdowntheroad.It'ssurelywiserto
routetheplumbingcorrectlynow,beforethewallsareup,thantotearholesinthemlater.Measuretwice,
cutonce.
Oneofthereasonsthatthewaterfallapproachwasabletoflourishagenerationagowasthatcomputers
andbusinessrequirementschangedatamoreleisurelypace.Hardwarewasveryexpensive,often
dwarfingthesalariesoftheprogrammershiredtotendit.Userinterfaceswereprimitivebytoday's
standards.Youcouldhaveanyuserinterfaceyouwanted,aslongasitwasanalphanumeric"green
screen".Anotherreasonforthepopularityofthewaterfallapproachwasthatitexhibitedacomfortable
similaritytopracticesinmorematureengineeringandmanufacturingdisciplines.
Today'sdesignersareconfrontedwithabroadonslaughtofchangingrequirements.Itarisesinpartfrom
therapidgrowthoftechnologyitself,andpartiallyfromrapidchangesinthebusinessclimate(someof
whichisdrivenbytechnology).Customersareusedtomoresophisticatedsoftwarethesedays,and
demandmorechoiceandflexibility.Productsthatwereoncebuiltfromthegroundupbyinhouse
programmersmustnowbeintegratedwiththirdpartycodeandapplications.Userinterfacesarecomplex,
bothexternallyandinternally.Indeed,weoftendedicateanentiretierofoursystemtotheircareand
feeding.Changethreatenstooutpaceourabilitytocopewithit.
http://www.laputan.org/mud/

16/36

1/6/2015

Big Ball of Mud

Masterplansareoftenrigid,misguidedandoutofdate.Usersneedschangewithtime.
Change:Thefundamentalproblemwithtopdowndesignisthatrealworldrequirementareinevitably
movingtargets.Youcan'tsimplyaspiretosolvetheproblemathandonceandforall,because,bythe
timeyou'redone,theproblemwillhavechangedoutfromunderneathyou.Youcan'tsimplydowhatthe
customerwants,forquiteoften,theydon'tknowwhattheywant.Youcan'tsimplyplan,youhavetoplan
tobeabletoadapt.Ifyoucan'tfullyanticipatewhatisgoingtohappen,youmustbepreparedtobe
nimble.
Aesthetics:Thegoalofupfrontdesignistobeabletodiscernandspecifythesignificantarchitectural
elementsofasystembeforegroundisbrokenforit.Asuperiordesign,giventhismindset,isonethat
elegantlyandcompletelyspecifiesthesystem'sstructurebeforeasinglelineofcodehasbeenwritten.
Mismatchesbetweentheseblueprintsandrealityareconsideredaberrations,andaretreatedasmistakes
onthepartofthedesigner.Abetterdesignwouldhaveanticipatedtheseoversights.Inthepresenceof
volatilerequirements,aspirationstowardssuchdesignperfectionareasvainasthedesireforaholein
oneoneveryhole.
Toavoidsuchembarrassment,thedesignermayattempttocoverhimorherselfbyspecifyingamore
complicated,andmoregeneralsolutiontocertainproblems,secureintheknowledgethatotherswillbear
theburdenofconstructingtheseartifacts.Whensuchpredictionsaboutwherecomplexityisneededare
correct,theycanindeedbeasourceofpowerandsatisfaction.ThisispartoftheirallureofVenustas.
However,sometimetheanticipatedcontingenciesneverarise,andthedesignerandimplementerswindup
havingwastedeffortsolvingaproblemthatnoonehaseveractuallyhad.Othertimes,notonlyisthe
anticipatedproblemneverencountered,itssolutionintroducescomplexityinapartofthesystemthat
turnsouttoneedtoevolveinanotherdirection.Insuchcases,speculativecomplexitycanbean
unnecessaryobstacletosubsequentadaptation.Itisironicthattheimpulsetowardselegancecanbean
unintendedsourceofcomplexityandclutterinstead.
Initsmostvirulentform,thedesiretoanticipateandheadoffchangecanleadto"analysisparalysis",as
thethickeningwebofimaginedcontingenciesgrowstothepointwherethedesignspaceseems
irreconcilablyconstrained.
Therefore,incrementallyaddressforcesthatencouragechangeandgrowth.Allowopportunitiesfor
growthtobeexploitedlocally,astheyoccur.Refactorunrelentingly.
Successfulsoftwareattractsawideraudience,whichcan,inturn,placeabroaderrangeofrequirements
onit.Thesenewrequirementscanrunagainstthegrainoftheoriginaldesign.Nonetheless,theycan
frequentlybeaddressed,butatthecostofcuttingacrossthegrainofexistingarchitecturalassumptions.
[Foote1988]calledthisarchitecturalerosionmidlifegeneralityloss.
Whendesignersarefacedwithachoicebetweenbuildingsomethingelegantfromthegroundup,or
underminingthearchitectureoftheexistingsystemtoquicklyaddressaproblem,architectureusually
loses.Indeed,thisisanaturalphaseinasystemsevolution[Foote&Opdyke1995].Thismightbe
thoughtofasmessykitchenphase,duringwhichpiecesofthesystemarescatteredacrossthecounter,
awaitinganeventualcleanup.Thedangeristhatthecleanupisneverdone.Withrealkitchens,theboard
ofhealthwilleventuallyintervene.Withsoftware,alas,thereisseldomanycorrespondingagencyto
policesuchsqualor.Uncontrolledgrowthcanultimatelybeamalignantforce.Theresultofneglectingto
containitcanbeaBIGBALLOFMUD.
InHowBuildingsLearn,Brand[Brand1994]observedthatwhathecalledHighRoadarchitectureoften
resultedinbuildingsthatwereexpensiveanddifficulttochange,whilevernacular,LowRoadbuildings
likebungalowsandwarehouseswere,paradoxically,muchmoreadaptable.BrandnotedthatFunction
meltsform,andlowroadbuildingsaremoreamenabletosuchchange.Similarly,withsoftware,youmay
bereluctanttodesecrateanotherprogrammerscathedral.Expedientchangestoalowroadsystemthat
exhibitsnodiscernablearchitecturalpretensionstobeginwithareeasiertorationalize.
IntheOregonExperiment[Brand1994][Alexander1988]Alexandernoted:
http://www.laputan.org/mud/

17/36

1/6/2015

Big Ball of Mud

Largelumpdevelopmentisbasedontheideaofreplacement.PiecemealGrowthisbasedonthe
ideaofrepair.Largelumpdevelopmentisbasedonthefallacythatitispossibletobuildperfect
buildings.Piecemealgrowthisbasedonthehealthierandmorerealisticviewthatmistakesare
inevitable.Unlessmoneyisavailableforrepairingthesemistakes,everybuilding,oncebuilt,is
condemnedtobe,tosomeextentunworkable.Piecemealgrowthisbasedontheassumptionthat
adaptationbetweenbuildingsandtheirusersisnecessarilyaslowandcontinuousbusinesswhich
cannot,underanycircumstances,beachieveinasingleleap.
Alexanderhasnotedthatourmortgageandcapitalexpenditurepoliciesmakelargesumsofmoney
availableupfront,butdonothingtoprovideresourcesformaintenance,improvement,andevolution
[Brand1994][Alexander1988].Inthesoftwareworld,wedeployourmostskilled,experiencedpeople
earlyinthelifecycle.Lateron,maintenanceisrelegatedtojuniorstaff,whenresourcescanbescarce.The
socalledmaintenancephaseisthepartofthelifecycleinwhichthepriceofthefictionofmasterplanning
isreallypaid.Itismaintenanceprogrammerswhoarecalledupontobeartheburdenofcopingwiththe
everwideningdivergencebetweenfixeddesignsandacontinuouslychangingworld.Ifthehypothesis
thatarchitecturalinsightemergeslateinthelifecycleiscorrect,thenthispracticeshouldbereconsidered.
BrandwentontoobserveMaintenanceislearning.Hedistinguishesthreelevelsoflearninginthe
contextofsystems.Thisfirstishabit,whereasystemdutifullyservesitsfunctionwithintheparameters
forwhichitwasdesigned.Thesecondlevelcomesintoplaywhenthesystemmustadapttochange.Here,
itusuallymustbemodified,anditscapacitytosustainsuchmodificationdeterminesitsdegreeof
adaptability.Thethirdlevelisthemostinteresting:learningtolearn.Withbuildings,addingaraised
floorisanexample.Havinghadtosustainamajorupheaval,thesystemadaptssothatsubsequent
adaptationswillbemuchlesspainful.
PIECEMEALGROWTHcanbeundertakeninanopportunisticfashion,startingwiththeexisting,living,
breathingsystem,andworkingoutward,astepatatime,insuchawayastonotunderminethesystems
viability.Youenhancetheprogramasyouuseit.Broadadvancesonallfrontsareavoided.Instead,
changeisbrokendownintosmall,manageablechunks.
OneofthemoststrikingthingsaboutPIECEMEALGROWTHistheroleplayedbyFeedback.Herbert
Simon[Simon1969]hasobservedthatfewoftheadaptivesystemsthathavebeenforgedbyevolutionor
shapedbymandependonpredictionastheirmainmeansofcopingwiththefuture.Henotesthattwo
complementarymechanisms,homeostasis,andretrospectivefeedback,areoftenfarmoreeffective.
Homeostasisinsulatesthesystemfromshortrangefluctuationsinitsenvironment,whilefeedback
mechanismsrespondtolongtermdiscrepanciesbetweenasystem'sactualanddesiredbehavior,and
adjustitaccordingly.Alexander[Alexander1964]haswrittenextensivelyoftherolesthathomeostasis
andfeedbackplayinadaptationaswell.
Ifyoucanadaptquicklytochange,predictingitbecomesfarlesscrucial.Hindsight,asBrandobserves
[Brand1994]isbetterthanforesight.SuchrapidadaptationisthebasisofoneofthemantrasofExtreme
Programming[Beck2000]:You'renotgoingtoneedit.
ProponentsofXP(asitiscalled)saytopretendyouarenotasmartasyouthinkyouare,andwaituntil
thiscleverideaofyoursisactuallyrequiredbeforeyoutakethetimetobringitintobeing.Inthecases
whereyouwereright,hey,yousawitcoming,andyouknowwhattodo.Inthecaseswhereyouwere
wrong,youwon'thavewastedanyeffortsolvingaproblemyou'veneverhadwhenthedesignheadsinan
unanticipateddirectioninstead.
ExtremeProgrammingreliesheavilyonfeedbacktokeeprequirementsinsyncwithcode,by
emphasizingshort(threeweek)iterations,andextensive,continuousconsultationwithusersregarding
designanddevelopmentprioritiesthroughoutthedevelopmentprocess.ExtremeProgrammersdonot
engageinextensiveupfrontplanning.Instead,theyproduceworkingcodeasquicklyaspossible,and
steertheseprototypestowardswhattheusersarelookingforbasedonfeedback.
Feedbackalsoplaysaroleindeterminingcodingassignments.Coderswhomissadeadlineareassigneda
differenttaskduringthenextiteration,regardlessofhowclosetheymayhavebeentocompletingthe
http://www.laputan.org/mud/

18/36

1/6/2015

Big Ball of Mud

task.Thisformoffeedbackresemblesthesternjusticemetedoutbythejungletothefruitof
uncompetitivepairings.
ExtremeProgrammingalsoemphasizestestingasanintegralpartofthedevelopmentprocess.Testsare
developed,ideally,beforethecodeitself.Codeiscontinuouslytestedasitisdeveloped.
Thereisa"backtothefuture"qualitytoExtremeProgramming.Inmanyrespects,itresemblestheblind
CodeandFixapproach.Thethingthatdistinguishesitisthecentralroleplayedbyfeedbackindriving
thesystem'sevolution.Thisevolutionisabetted,inturn,bymodernobjectorientedlanguagesand
powerfulrefactoringtools.
Proponentsofextremeprogrammingportrayitasplacingminimalemphasisonplanningandupfront
design.Theyrelyinsteadonfeedbackandcontinuousintegration.Webelievethatacertainamountofup
frontplanninganddesignisnotonlyimportant,butinevitable.Noonereallygoesintoanyproject
blindly.Thegroundworkmustbelaid,theinfrastructuremustbedecidedupon,toolsmustbeselected,
andageneraldirectionmustbeset.Afocusonasharedarchitecturalvisionandstrategyshouldbe
establishedearly.
Unbridled,changecanunderminestructure.Orderlychangecanenhanceit.Changecanengender
malignantsprawl,orhealthy,orderlygrowth.
vvv
Abroadconsensusthatobjectsemergefromaniterativeincrementalevolutionaryprocesshasformedin
theobjectorientedcommunityoverthelastdecade.Seeforinstance[Booch1994].TheSOFTWARE
TECTONICSpattern[Foote&Yoder1996]examineshowsystemscanincrementallycopewithchange.
ThebiggestriskassociatedwithPIECEMEALGROWTHisthatitwillgraduallyerodetheoverall
structureofthesystem,andinexorablyturnitintoaBIGBALLOFMUD.AstrategyofKEEPINGIT
WORKINGgoeshandinhandwithPIECEMEALGROWTH.Bothpatternsemphasizeacute,local
concernsattheexpenseofchronic,architecturalones.
Tocounteracttheseforces,apermanentcommitmenttoCONSOLIDATIONandrefactoringmustbe
made.Itisthroughsuchaprocessthatlocalandglobalforcesarereconciledovertime.Thislifecyle
perspectivehasbeendubbedthefractalmodel[Foote&Opdyke1995].ToquoteAlexander[Brand1994]
[Alexander1988]:
Anorganicprocessofgrowthandrepairmustcreateagradualsequenceofchanges,andthese
changesmustbedistributedevenlyacrossalllevelsofscale.[Indevelopingacollegecampus]
theremustbeasmuchattentiontotherepairofdetailsrooms,wingsofbuildings,windows,paths
astothecreationofbrandnewbuildings.Onlythencantheenvironmentbebalancedbothasa
whole,andinitsparts,ateverymomentinitshistory.

KEEPITWORKING
alias
VITALITY
BABYSTEPS
DAILYBUILD
FIRST,DONOHARM
Probablythegreatestfactorthatkeepsusmovingforwardisthatweusethesystemall
thetime,andwekeeptryingtodonewthingswithit.Itisthis"livingwith"which
drivesustorootoutfailures,tocleanupinconsistencies,andwhichinspiresour
http://www.laputan.org/mud/

19/36

1/6/2015

Big Ball of Mud

occasionalinnovation.
DanielH.H.Ingalls[Ingalls1983]

Onceacityestablishesitsinfrastructure,itisimperativethatitbekeptworking.
Forexample,ifthesewersbreak,andarentquicklyrepaired,theconsequences
canescalatefrommerelyunpleasanttogenuinelylifethreatening.Peoplecome
toexpectthattheycanrelyontheirpublicutilitiesbeingavailable24hoursper
day.They(rightfully)expecttobeabletodemandthatanoutagebetreatedas
anemergency.
vvv
Softwarecanbelikethis.Oftenabusinessbecomesdependentuponthedata
drivingit.Businesseshavebecomecriticallydependentontheirsoftwareand
computinginfrastructures.Therearenumerousmissioncriticalsystemsthatmustbeontheairtwenty
fourhoursaday/sevendaysperweek.Ifthesesystemsgodown,inventoriescannotbechecked,
employeescannotbepaid,aircraftcannotberouted,andsoon.
Theremaybetimeswheretakingasystemdownforamajoroverhaulcanbejustified,butusually,doing
soisfraughtwithperil.However,oncethesystemisbroughtbackup,itisdifficulttotellwhichfrom
amongalargecollectionofmodificationsmighthavecausedanewproblem.Everychangeissuspect.
Thisiswhydeferringsuchintegrationisarecipeformisery.CapersJones[Jones1999]reportedthatthe
chancethatasignificantchangemightcontainanewerroraphenomenonheominouslyreferredtoasa
BadFixInjectionwasabout7%intheUnitedStates.Thismaystrikesomereadersasalowfigure.Still,
it'seasytoseethatcompoundingthispossibilitycanleadtoasituationwheremultipleupgradesare
increasinglikelytobreakasystem.
Maintenanceneedshaveaccumulated,butanoverhaulisunwise,sinceyoumightbreakthesystem.
Workmanship:Architectswholiveinthehousetheyarebuildinghaveanobviousincentivetoinsurethat
thingsaredoneproperly,sincetheywilldirectlyreaptheconsequenceswhentheydonot.Theideaofthe
architectbuilderisacentralthemeofAlexander'swork.Whobettertoresolvetheforcesimpingingupon
eachdesignissueasitarisesasthepersonwhoisgoingtohavetolivewiththesedecisions?The
architectbuilderwillbethedirectbeneficiaryofhisorherownworkmanshipandcare.Mistakesand
shortcutswillmerelyfoulhisorherownnest.
Dependability:Thesedays,peoplerelyonoursoftwareartifactsfortheirverylivelihoods,andeven,at
time,fortheirverysafety.Itisimperativethatilladvisechangestoelementsofasystemdonotdragthe
entiresystemdown.Modernsoftwaresystemsareintricate,elaboratewebsofinterdependentelements.
Whenanessentialelementisbroken,everyonewhodependsonitwillbeaffected.Deadlinescanbe
missed,andtemperscanflare.ThisproblemisparticularlyacuteinBIGBALLSOFMUD,sinceasingle
failurecanbringtheentiresystemdownlikeahouseofcards.
Therefore,dowhatittakestomaintainthesoftwareandkeepitgoing.Keepitworking.
Whenyouarelivinginthesystemyourebuilding,youhaveanacuteincentivenottobreakanything.A
plumbingoutagewillbeadirectinconvenience,andhenceyouhaveapowerfulreasontokeepitbrief.
Youare,attimes,workingwithlivewires,andmustexhibitparticularcare.Amajorbenefitofworking
withalivesystemisthatfeedbackisdirect,andnearlyimmediate.
Oneofthestrengthsofthisstrategyisthatmodificationsthatbreakthesystemarerejectedimmediately.
Therearealwaysalargenumberofpathsforwardfromanypointinasystemsevolution,andmostof
themleadnowhere.Byimmediatelyselectingonlythosethatdonotunderminethesystemsviability,
obviousdeadendsareavoided.
Ofcourse,thissortofreactiveapproach,thatofkickingthenearest,meanestwoolffromyourdoor,isnot
necessarilygloballyoptimal.Yet,byeliminatingobviouswrongturns,onlymoreinsidiouslyincorrect
http://www.laputan.org/mud/

20/36

1/6/2015

Big Ball of Mud

pathsremain.Whilethesearealwayshardertoidentifyandcorrect,theyare,fortunatelylessnumerous
thanthosecaseswherethebestimmediatechoiceisalsothebestoverallchoiceaswell.
Itmayseemthatthisapproachonlyaccommodatesminormodifications.Thisisnotnecessarilyso.Large
newsubsystemsmightbeconstructedofftotheside,perhapsbyseparateteams,andintegratedwiththe
runningsysteminsuchawayastominimizedistruption.
Designspacemightbethoughtofasavast,dark,largelyunexploredforest.Usefulpotentialpaths
throughitmightbethoughtofasencompassingworkingprograms.Thespaceofftothesidesofthese
pathsismuchlargerrealmofnonworkingprograms.Fromanygivenpoint,afewsmallstepsinmost
directionstakeyoufromaworkingtoanonworkingprogram.Fromtimetotime,thereareforksinthe
path,indicatingachoiceamongworkingalternatives.Inunexploredterritory,theprudentstrategyis
nevertostraytoofarfromthepath.Now,ifonehasamap,ashortcutthroughthetreklessthicketthat
mightsavemilesmaybeevident.Ofcourse,pioneers,bydefinition,donthavemaps.Bytakingsmall
stepsinanydirection,theyknowthatitisnevermorethanafewstepsbacktoaworkingsystem.
Someyearsago,HarlanMillsproposedthatanysoftwaresystemshouldbegrownby
incrementaldevelopment.Thatis,thesystemfirstbemadetorun,eventhoughitdoes
nothingusefulexceptcallthepropersetofdummysubprograms.Then,bitbybit,itis
fleshedout,withthesubprogramsinturnbeingdevelopedintoactionsorcallsto
emptystubsinthelevelbelow.

Nothinginthepastdecadehassoradicallychangedmyownpractice,andits
effectiveness.

Onealwayshas,ateverystage,intheprocess,aworkingsystem.Ifindthatteamscan
growmuchmorecomplexentitiesinfourmonthsthantheycanbuild.
From"NoSilverBullet"[Brooks1995]

MicrosoftmandatesthataDAILYBUILDofeachproductbeperformedattheendofeachworkingday.
Norteladherestotheslightlylessdemandingrequirementthataworkingbuildbegeneratedattheendof
eachweek[Brooks1995][Cusumano&Shelby1995].Indeed,thisapproach,andkeepingthelast
workingversionaround,arenearlyuniversalpracticesamongsuccessfulmaintenanceprogrammers.
Anothervitalfactorinensuringasystem'scontinuedvitalityisacommitmenttorigoroustesting[Marick
1995][Bach1994].It'shardtokeepasystemworkingifyoudon'thaveawayofmakingsureitworks.
TestingisoneofpillarsofExtremeProgramming.XPpracticescallforthedevelopmentofunittests
beforeasinglelineofcodeiswritten.
vvv
AlwaysbeginningwithaworkingsystemhelpstoencouragePIECEMEALGROWTH.Refactoringisthe
primarymeansbywhichprogrammersmaintainorderfrominsidethesystemsinwhichtheyareworking.
Thegoalofrefactoringistoleaveasystemworkingaswellafterarefactoringasitwasbeforethe
refactoring.Aggressiveunitandintegrationtestingcanhelptoguaranteethatthisgoalismet.

SHEARINGLAYERS

http://www.laputan.org/mud/

21/36

1/6/2015

Big Ball of Mud

Hummingbirdsandflowersarequick,redwoodtreesareslow,andwholeredwoodforests
areevenslower.Mostinteractioniswithinthesamepacelevelhummingbirdsand
flowerspayattentiontoeachother,oblivioustoredwoods,whoareoblivioustothem.
R.V.O'Neill,AHierarchicalConceptofEcosystems

ThenotionofSHEARINGLAYERSisoneofthecenterpiecesofBrand'sHowBuildingsLearn[Brand
1994].Brand,inturnsynthesizedhisideasfromavarietyofsources,includingBritishdesignerFrank
Duffy,andecologistR.V.O'Neill.
BrandquotesDuffyassaying:"Ourbasicargumentis
thatthereisn'tanysuchthingasabuilding.Abuilding
properlyconceivedisseverallayersoflongevityof
builtcomponents".
BranddistilledDuffy'sproposedlayersintothesesix:
Site,Structure,Skin,Services,SpacePlan,andStuff.
Siteisgeographicalsetting.Structureistheload
bearingelements,suchasthefoundationandskeleton.
Skinistheexteriorsurface,suchassidingand
windows.Servicesarethecirculatoryandnervous
systemsofabuilding,suchasitsheatingplant,wiring,
andplumbing.TheSpacePlanincludeswalls,
flooring,andceilings.Stuffincludeslamps,chairs,appliances,bulletinboards,andpaintings.
Theselayerschangeatdifferentrates.Site,theysay,iseternal.Structuremaylastfrom30to300years.
Skinlastsforaround20years,asitrespondstotheelements,andtothewhimsoffashion.Services
succumbtowearandtechnicalobsolescencemorequickly,in7to15years.CommercialSpacePlansmay
turnoverevery3years.Stuff,is,ofcourse,subjecttounrelentingflux[Brand1994].
vvv
Softwaresystemscannotstandstill.Softwareisoftencalledupontobearthebruntofchanging
requirements,because,beingasthatitismadeofbits,itcanchange.
Differentartifactschangeatdifferentrates.
Adaptability:Asystemthatcancopereadilywithawiderangeofrequirements,will,allotherthings
beingequal,haveanadvantageoveronethatcannot.Suchasystemcanallowunexpectedrequirementsto
bemetwithlittleornoreengineering,andallowitsmoreskilledcustomerstorapidlyaddressnovel
challenges.
Stability:Systemssucceedbydoingwhattheyweredesignedtodoaswellastheycandoit.Theyearn
http://www.laputan.org/mud/

22/36

1/6/2015

Big Ball of Mud

theirniches,bybetteringtheircompetitionalongoneormoredimensionssuchascost,quality,features,
andperformance.See[Foote&Roberts1998]foradiscussionoftheoccasionallyficklenatureofsuch
completion.Oncetheyhavefoundtheirniche,forwhateverreason,itisessentialthatshorttermconcerns
notbeallowedtowashawaytheelementsofthesystemthataccountfortheirmasteryoftheirniche.Such
victoriesareinevitablyhardwon,andfruitsofsuchvictoriesshouldnotbesquandered.Thosepartsofthe
systemthatdowhatthesystemdoeswellmustbeprotectedfromfads,whims,andothersuchspasmsof
poorjudgement.
AdaptabilityandStabilityareforcesthatareinconstanttension.Ononehand,systemsmustbeableto
confrontnoveltywithoutblinking.Ontheother,theyshouldnotsquandertheirpatrimonyonspurofthe
momentmisadventures.
Therefore,factoryoursystemsothatartifactsthatchangeatsimilarratesaretogether.
Mostinteractionsinasystemtendtobewithinlayers,orbetweenadjacentlayers.Individuallayerstend
tobeaboutthingsthatchangeatsimilarrates.Thingsthatchangeatdifferentratesdiverge.Differential
ratesofchangeencouragelayerstoemerge.Brandnotesaswellthatoccupationalspecialtiesemerge
alongwiththeselayers.Therateatwhichthingschangeshapesourorganizationsaswell.Forinstance,
decoratorsandpaintersconcernthemselveswithinteriors,whilearchitectsdwellonsiteandskin.We
expecttoseethingsthatevolveatdifferentratesemergeasdistinctconcerns.Thisis"separatethatwhich
changesfromthatwhichdoesn't"[Roberts&Johnson1998]writlarge.
Canweidentifysuchlayersinsoftware?
Well,atthebottom,therearedata.Thingsthatchangemostquicklymigrateintothedata,sincethisisthe
aspectofsoftwarethatismostamenabletochange.Data,inturn,interactwithusersthemselves,who
produceandconsumethem.
Codechangesmoreslowlythandata,andistherealmofprogrammers,analystsanddesigners.Inobject
orientedlanguages,thingsthatwillchangequicklyarecastasblackboxpolymorphiccomponents.
Elementsthatwillchangelessoftenmayemploywhiteboxinheritance.
Theabstractclassesandcomponentsthatconstituteanobjectorientedframeworkchangemoreslowly
thantheapplicationsthatarebuiltfromthem.Indeed,theirroleistodistillwhatiscommon,and
enduring,fromamongtheapplicationsthatseededtheframework.
Asframeworksevolve,certainabstractionsmaketheirwaysfromindividualapplicationsintothe
frameworksandlibrariesthatconstitutethesystem'sinfrastructure[Foote1988].Notallelementswill
makethisjourney.Notallshould.Thosethatdoareamongthemostvaluablelegaciesoftheprojectsthat
spawnthem.Objectshelpshearinglayerstoemerge,becausetheyprovideplaceswheremorefine
grainedchunksofcodeandbehaviorthatbelongtogethercancoalesce.
TheSmalltalkprogramminglanguageisbuiltfromasetofobjectsthathaveproventhemselvestobeof
particularvaluetoprogrammers.Languageschangemoreslowlythanframeworks.Theyarethepurview
ofscholarsandstandardscommittees.Oneofthetraditionalfunctionsofsuchbodiesistoensurethat
languagesevolveatasuitablydeliberatepace.
Artifactsthatevolvequicklyprovideasystemwithdynamismandflexibility.Theyallowasystemtobe
fastonitsfeetinthefaceofchange.
Slowlyevolvingobjectsarebulwarksagainstchange.Theyembodythewisdomthatthesystemhas
accruedinitspriorinteractionswithitsenvironment.Liketenure,tradition,bigcorporations,and
conservativepolitics,theymaintainwhathasworked.Theyworkedonce,sotheyarekeptaround.They
hadagoodideaonce,somaybetheyareabetterthanevenbettohaveanotherone.
Wideacceptanceanddeploymentcausesresistancetochange.Ifchangingsomethingwillbreakalotof
code,thereisconsiderableincentivenottochangeit.Forexample,schemareorganizationinlarge
http://www.laputan.org/mud/

23/36

1/6/2015

Big Ball of Mud

enterprisedatabasescanbeanexpensiveandtimeconsumingprocess.Databasedesignersand
administratorslearntoresistchangeforthisreason.Separatejobdescriptions,andseparatehardware,
togetherwithdistincttiers,helptomakethesetiersdistinct.
Thephenomenonwherebydistinctconcernsemergeasdistinctlayersandtierscanbeseenaswellwith
graphicaluserinterfaces.
PartoftheimpetusbehindusingMETADATA[Foote&Yoder1998b]istheobservationthatpushing
complexityandpowerintothedatapushesthatsamepower(andcomplexity)outoftherealmofthe
programmerandintotherealmofusersthemselves.Metadataareoftenusedtomodelstaticfacilitiessuch
asclassesandschemas,inordertoallowthemtochangedynamically.Theeffectisanalogoustothatseen
withmodularofficefurniture,whichallowsofficeworkerstoeasily,quickly,andcheaplymovepartitions
withouthavingtoenlistarchitectsandcontractorsintheeffort.
Overtime,ourframeworks,abstractclasses,andcomponentscometoembodywhatwe'velearnedabout
thestructureofthedomainsforwhichtheyarebuilt.Moreenduringinsightsgravitatetowardsthe
primarystructuralelementsofthesesystems.Thingswhichfindthemselvesinfluxarespunoutintothe
data,whereuserscaninteractwiththem.Softwareevolutionbecomeslikeacentrifugespunbychange.
Thelayersthatresult,overtime,cancometoamuchtrueraccommodationwiththeforcesthatshaped
themthananytopdownagendacouldhavedevised.
Thingsthataregoodhaveacertainkindofstructure.Youcantgetthatstructure
exceptdynamically.Period.Innatureyouvegotcontinuousverysmallfeedbackloop
adaptationgoingon,whichiswhythingsgettobeharmonious.Thatswhytheyhavethe
qualitieswevalue.Ifitwasntforthetimedimension,itwouldnthappen.Yethere
weareplayingthemajorrolecreatingtheworld,andwehaventfiguredthisout.That
isaveryseriousmatter.
ChristopherAlexander[Brand1994]

vvv
ThispatternhasmuchincommonwiththeHOTSPOTSpatterndiscussedin[Roberts&Johnson1998].
Indeed,separatingthingsthatchangefromthosethatdonotiswhatdrivestheemergenceofSHEARING
LAYERS.Theselayersaretheresultofsuchdifferentialratesofchange,whileHOTSPOTSmightbe
thoughtofastherupturezonesinthefaultlinesalongwhichslippagebetweenlayersoccurs.This
tectonicslippageissuggestiveaswelloftheSOFTWARETECTONICSpattern[Foote&Yoder1996],
whichrecommendsfinegrainediterationasameansofavoidingcatastrophicupheaval.METADATA
http://www.laputan.org/mud/

24/36

1/6/2015

Big Ball of Mud

andACTIVEOBJECTMODELS[Foote&Yoder1998b]allowsystemstoadaptmorequicklyto
changingrequirementsbypushingpowerintothedata,andoutontousers.

SWEEPINGITUNDERTHERUG
alias
POTEMKINVILLAGE
HOUSECLEANING
PRETTYFACE
QUARANTINE
HIDINGITUNDERTHEBED
REHABILITATION

Oneofthemostspectacularexamplesofsweepingaproblemundertherugisthe
concretesarcophagusthatSovietengineersconstructedtoputa10,000yearlidonthe
infamousreactornumberfouratChernobyl,inwhatisnowUkraine.

Ifyoucantmakeamessgoaway,atleastyoucanhideit.Urbanrenewalcanbeginbypaintingmurals
overgraffitiandputtingfencesaroundabandonedproperty.Childrenoftenlearnthatasingleheapinthe
closetisbetterthanascatteredmessinthemiddleofthefloor.
vvv
Therearereasons,otherthanaestheticconcerns,professionalpride,andguiltfortryingtocleanupmessy
code.Adeadlinemaybenearing,andacolleaguemaywanttocallachunkofyourcode,ifyoucould
onlycomeupwithaninterfacethroughwhichitcouldbecalled.Ifyoudontcomeupwithaneasyto
understandinterface,theylljustusesomeoneelses(perhapsinferior)code.Youmightbecowering
duringacodereview,asyourpeerstrudgethroughaparticularlyundistinguishedexampleofyourwork.
Youknowthattherearegoodideasburiedinthere,butthatifyoudontstarttomakethemmoreevident,
theymaybelost.
Thereisalimittohowmuchchaosanindividualcantoleratebeforebeingoverwhelmed.Atfirstglance,
aBIGBALLOFMUDcaninspireterroranddespairintheheartsofthosewhowouldtrytotameit.The
firststepontheroadtoarchitecturalintegritycanbetoidentifythedisorderedpartsofthesystem,and
isolatethemfromtherestofit.Oncetheproblemareasareidentifiedandhemmedin,theycanbe
gentrifiedusingadivideandconquerstrategy.
http://www.laputan.org/mud/

25/36

1/6/2015

Big Ball of Mud

Overgrown,tangled,haphazardspaghetticodeishardtocomprehend,repair,orextend,andtends
togrowevenworseifitisnotsomehowbroughtundercontrol.
Comprehensibility:Itshouldgowithoutsayingthat
comprehensible,attractive,wellengineeredcodewillbeeasier
tomaintainandextendthancomplicated,convolutedcode.
However,ittakesTimeandmoneytooverhaulsloppycode.
Still,theCostofallowingittofesterandcontinuetodecline
shouldnotbeunderestimated.
Morale:Indeed,thepriceoflifewithaBIGBALLOFMUD
goesbeyondthebottomline.Lifeinthemuddytrenchescan
beadispiritingfate.Makingevenminormodificationscan
leadtomaintenancemarathons.Programmersbecometimid,
afraidthattuggingataloosethreadmayhaveunpredictable
consequences.Afterawhile,themyriadthreadsthatcouple
everypartofthesystemtoeveryothercometotiethe
programmerdownassurelyasGulliveramongtheLilliputians
[Swift1726].Talentmaydeserttheprojectinthefaceofsuchbondage.
Itshouldgowithoutsayingthatcomprehensible,attractive,wellengineeredcodewillbeeasierto
maintainandextendthancomplicated,convolutedcode.However,ittakestimeandmoneytooverhaul
sloppycode.Still,thecostofallowingittofesterandcontinuetodeclineshouldnotbeunderestimated.
Therefore,ifyoucanteasilymakeamessgoaway,atleastcordonitoff.Thisrestrictsthedisorder
toafixedarea,keepsitoutofsight,andcansetthestageforadditionalrefactoring.
Bygettingthedirtintoasinglepilebeneaththecarpet,youatleastknowwhereitis,andcanmoveit
around.Youvestillgotapileofdirtonyourhands,butitislocalized,andyourguestscantseeit.Asthe
engineerswhoentombedreactornumberfouratChernoblydemonstrated,sometimesyou'vegottogeta
lidonaproblembeforeyoucangetseriousaboutcleaningthingsup.Oncetheproblemareaiscontained,
youcandecontaminateatamoreleisurelypace.
Tobegintogetahandleonspaghetticode,findthose
sectionsofitthatseemlesstightlycoupled,andstartto
drawarchitecturalboundariesthere.Separatetheglobal
informationintodistinctdatastructures,andenforce
communicationbetweentheseenclavesusingwell
definedinterfaces.Suchstepscanbethefirstonesonthe
roadtoreestablishingthesystemsconceptualintegrity,
anddiscerningnascentarchitecturallandmarks.
Puttingafreshinterfacearoundarundownregionofthe
systemcanbethefirststeponthewayarchitectural
rehabilitation.Thisisalongrowtohoe,however.
DistillingmeaningfulabstractionsfromaBIGBALLOFMUDisadifficultanddemandtask.Itrequires
skill,insight,andpersistence.Attimes,RECONSTRUCTIONmayseemlikethelesspainfulcourse.
Still,itisnotlikeunscramblinganegg.Aswithrehabilitationintherealworld,restoringasystemto
architecturalhealthrequiresresources,aswellasasustainedcommitmentonthepartofthepeoplewho
livethere.
TheUIMXuserinterfacebuilderforUnixandMotif,andthevariousSmalltalkGUIbuildersboth
provideameansforprogrammerstocordonoffcomplexityinthisfashion.
vvv
OnefrequentlyconstructsaFAADE[Gammaet.al.1995]toputacongenial"prettyface"onthe
http://www.laputan.org/mud/

26/36

1/6/2015

Big Ball of Mud

unpleasantnessthatisSWEPTUNDERTHERUG.Oncethesemessychunksofcodehavebeen
quarantined,youcanexposetheirfunctionalityusingINTENTIONREVEALINGSELECTORS[Beck
1997].
ThiscanbethefirststepontheroadtoCONSOLIDATIONtoo,sinceonecanbegintohemin
unregulatedgrowththanmayhaveoccurredduringPROTOTYPINGorEXPANSION[Foote&Opdyke
1995].[Foote&Yoder1998a]exploreshow,ironically,inscrutablecodecanpersistbecauseitisdifficult
tocomprehend.
Thispaperalsoexamineshowcomplexitycanbehiddenusingsuitabledefaults(WORKSOUTOFTHE
BOXandPROGRAMMINGBYDIFFERRENCE),andinterfacesthatgraduallyrevealadditional
capabilitiesastheclientgrowsmoresophisticated.

RECONSTRUCTION
alias
TOTALREWRITE
DEMOLITION
THROWAWAYTHEFIRSTONE
STARTOVER

AtlantasFultonCountyStadiumwasbuiltin1966toserveasthehomeofbaseballsAtlantaBraves,and
footballsAtlantaFalcons.InAugustof1997,thestadiumwasdemolished.Twofactorscontributedtoits
relativelyrapidobsolescence.Onewasthatthearchitectureoftheoriginalstadiumwasincapableof
accommodatingtheadditionofthe"skybox"suitesthatthespreadsheetsof90ssportingeconomics
demanded.Noconceivableretrofitcouldaccommodatethisrequirement.Addressingitmeantstarting
over,fromthegroundup.Thesecondwasthatthestadiumsattempttoprovideacheap,generalsolution
totheproblemofprovidingaforumforbothbaseballandfootballaudiencescompromisedtheneedsof
both.Inonlythirtyoneyears,thebalanceamongtheseforceshadshifteddecidedly.Thefacilityisbeing
replacedbytwonewsinglepurposestadia.
Mighttherebelessonsforusaboutunexpectedrequirementsanddesigninggeneralcomponentshere?
vvv
PlantoThrowOneAway(YouWillAnyway)Brooks

ExtremeProgramming[Beck2000]haditsgenesisintheChryslerComprehensiveCompensationproject
(C3).Itbeganwithacryforhelpfromafounderingproject,andadecisiontodiscardayearandahalf's
worthofwork.TheprocesstheyputinplaceaftertheystartedanewlaidthefoundationforXP,andthe
author'scredittheseapproachesforthesubsequentsuccessoftheC3effort.However,lessemphasisis
giventovalueoftheexperiencetheteammighthavesalvagedfromtheirinitial,unsuccessfuldraft.Could
http://www.laputan.org/mud/

27/36

1/6/2015

Big Ball of Mud

thisfirstdrafthavebeentheunsungheroofthistale?
Yourcodehasdeclinedtothepointwhereitisbeyondrepair,orevencomprehension.
Obsolescence:Ofcourse,onereasontoabandonasystemisthatitisinfacttechnicallyoreconomically
obsolete.Thesearedistinctsituations.Asystemthatisnolongerstateoftheartmaystillsellwell,while
atechnicallysuperiorsystemmaybeoverwhelmedbyamorepopularcompetitorfornontechnical
reasons.
Intherealmofconcreteandsteel,blightisthesymptom,andawithdrawalofcapitalisthecause.Of
course,oncethisprocessbegins,itcanfeedonitself.Ontheotherhand,givenasteadyinfusionof
resources,buildingscanlastindefinitely.It'snotmerelyentropy,butanunwillingnesstocounteractit,
thatallowsbuildingstodecline.InEurope,neighborhoodshaveflourishedforhundredsofyears.They
haveavoidedtheboom/bustcyclesthatcharacterizesomeNewWorldcities.
Change:Eventhoughsoftwareisahighlymalleablemedium,likeFultonCountyStadium,newdemands
can,attimes,cutacrossasystemsarchitecturalassumptionsinsuchawaysastomakeaccommodating
themnexttoimpossible.Insuchcases,atotalrewritemightbetheonlyanswer.
Cost:Writingoffasystemcanbetraumatic,bothtothosewhohaveworkedonit,andtothosewhohave
paidforit.Softwareisoftentreatedasanassetbyaccountants,andcanbeanexpensiveassetatthat.
Rewritingasystem,ofcourse,doesnotdiscarditsconceptualdesign,oritsstaffsexperience.Ifitistruly
thecasethatthevalueoftheseassetsisinthedesignexperiencetheyembody,thenaccountingpractices
mustrecognizethis.
Organization:Rebuildingasystemfromscratchisahighprofileundertaking,thatwilldemand
considerabletimeandresources,which,inturn,willmakehighlevelmanagementsupportessential.
Therefore,throwitawayandstartover.
Sometimesitsjusteasiertothrowasystemaway,andstartover.Examplesabound.Ourshelvesare
litteredwiththediscardedcarcassesofobsoletesoftwareanditsdocumentation.Startingovercanbeseen
asadefeatatthehandsoftheoldcode,oravictoryoverit.
Onereasontostartovermightbethattheprevious
systemwaswrittenbypeoplewhoarelonggone.
Doingarewriteprovidesnewpersonnelwithawayto
reestablishcontactbetweenthearchitectureandthe
implementation.Sometimestheonlywayto
understandasystemitistowriteityourself.Doinga
freshdraftisawaytoovercomeneglect.Issuesare
revisited.Afreshdraftaddsvigor.Youdrawbackto
leap.Thequagmirevanishes.Theswampisdrained.
Anothermotivationforbuildinganewsystemmightbethatyoufeelthatyou'vegottheexperienceyou
needtodothejobproperly.Onewaytohavegottenthisexperienceistohaveparticipatedatsomelevel
intheunsuccessfuldevelopmentofapreviousversionofthesystem.
Ofcourse,thenewsystemisnotdesignedinavacuum.Brooksfamoustarpitisexcavated,andthe
fossilsareexamined,toseewhattheycantelltheliving.Itisessentialthatathoroughpostmortem
reviewbedoneoftheoldsystem,toseewhatitdidwell,andwhyitfailed.Badcodecanbogdowna
gooddesign.Agooddesigncanisolateandcontainbadcode.
WhenasystembecomesaBIGBALLOFMUD,itsrelativeincomprehensibilitymayhastenitsdemise,
bymakingitdifficultforittoadapt.Itcanpersist,sinceitresistschange,butcannotevolve,forthesame
reason.Instead,itsinscrutability,evenwhenitistoitsshorttermbenefit,sowstheseedsofitsultimate
demise.
http://www.laputan.org/mud/

28/36

1/6/2015

Big Ball of Mud

Ifthismakesmuddinessafrequentlyterminalcondition,isthisreallyabadthing?Orisitablessingthat
thesescleroticsystemsyieldthestagetomoreagilesuccessors?Certainly,thedepartureofthese
ramshacklerelicscanbeacauseforcelebrationaswellassadness.
Discardingasystemdispenseswithitsimplementation,andleavesonlyits
conceptualdesignbehind.Onlythepatternsthatunderliethesystemremain,
grinninglikeaCheshirecat.Itistheirspiritsthathelptoshapethenext
implementation.Withluck,thesearchitecturalinsightswillbereincarnatedas
genuinereusableartifactsinthenewsystem,suchasabstractclassesand
frameworks.Itisbyfindingthesearchitecturalnuggetsthatthepromiseofobjectsandreusecanfinally
befulfilled.
Therearealternativestothrowningyoursystemawayandstartingover.Oneistoembarkonaregimenof
incrementalrefactoring,togleanarchitecturalelementsanddiscernableabstractionsfromthemire.
Indeed,youcanbeginbylookingforcoarsefissuresalongwhichtoseparatepartsofthesystem,aswas
suggestedinSWEEPINGITUNDERTHERUG.Ofcourse,refactoringismoreeffectiveasa
prophylacticmeasurethatasalastrestorttherapy.Aswithanyedifice,itisajudgementcall,whetherto
rehaborrestortforthewreckingball.Anotheralternativeistoreassesswhethernewcomponentsand
frameworkshavecomealongthatcanreplaceallorpartofthesystem.Whenyoucanreuseandretrofit
otherexistingcomponents,youcanspareyourselfthetimeandexpenseinvolvedinrebuilding,repairing,
andmaintainingtheoneyouhave.
TheUnitedStatesCommerceDepartmentdefinesdurablegoodsasthosethataredesignedtolastfor
threeyearsormore.Thiscategorytraditionallyappliedtogoodssuchasfurniture,appliances,
automobiles,andbusinessmachines.Ironically,ascomputerequipmentisdepreciatingevermore
quickly,itisincreasinglyoursoftwareartifacts,andnotourhardware,thatfulfillthiscriterion.Firmitas
hascometotherealmofbitsandbytes.
Apple'sLisaToolkit,anditssuccessor,theMacintoshToolbox,constituteoneofthemoreintriguing
examplesof
RECONSTRUCTIONinthehistoryofpersonalcomputing.
Anarchitect'smostusefultoolsareaneraseratthedraftingboard,andawrecking
baratthesite
FrankLloydWright

vvv
TheSOFTWARETECTONICSpatterndiscussedin[Foote&Yoder1996]observesthatifincremental
changeisdeferredindefinitely,majorupheavalmaybetheonlyalternative.[Foote&Yoder1998a]
explorestheWINNINGTEAMphenomenon,wherebyotherwisesuperiortechnicalsolutionsare
overwhelmedbynontechnicalexigencies.
Brookshaseloquentlyobservedthatthemostdangeroussystemanarchitectwilleverdesignishisorher
secondsystem[Brooks1995].Thisisthenotorioussecondsystemeffect.RECONSTRUCTIONprovides
anopportunityforthismisplacedhubristoexerciseitself,soonemustkeepawaryeyeopenforit.Still,
therearetimeswhenthebestandonlywaytomakeasystembetteristothrowitawayandstartover.
Indeed,onecandoworsethantoheedBrook'sclassicadmonitionthatyoushould"plantothrowone
away,youwillanyway".

http://www.laputan.org/mud/

29/36

1/6/2015

Big Ball of Mud

MirreenterstheatmosphereoverFijion22March,2001

Conclusion
Intheend,softwarearchitectureisabouthowwedistillexperienceintowisdom,anddisseminateit.We
thinkthepatternshereinstandalongsideotherworkregardingsoftwarearchitectureandevolutionthatwe
citedaswewentalong.Still,wedonotconsiderthesepatternstobeantipatterns.Therearegoodreasons
thatgoodprogrammersbuildBIGBALLSOFMUD.Itmaywellbethattheeconomicsofthesoftware
worldaresuchthatthemarketmovessofastthatlongtermarchitecturalambitionsarefoolhardy,andthat
expedient,slashandburn,disposableprogrammingis,infact,astateoftheartstrategy.Thesuccessof
theseapproaches,inanycase,isundeniable,andsealstheirpatternhood.Peoplebuild
BIGBALLSOFMUDbecausetheywork.Inmanydomains,theyaretheonlythingsthathavebeen
showntowork.Indeed,theyworkwhereloftierapproacheshaveyettodemonstratethattheycan
compete.
ItisnotourpurposetocondemnBIGBALLSOFMUD.Casualarchitectureisnaturalduringtheearly
stagesofasystemsevolution.Thereadermustsurelysuspect,however,thatourhopeisthatwecan
aspiretodobetter.Byrecognizingtheforcesandpressuresthatleadtoarchitecturalmalaise,andhowand
whentheymightbeconfronted,wehopetosetthestagefortheemergenceoftrulydurableartifactsthat
canputarchitectsindominantpositionsforyearstocome.Thekeyistoensurethatthesystem,its
programmers,and,indeedtheentireorganization,learnaboutthedomain,andthearchitectural
opportunitiesloomingwithinit,asthesystemgrowsandmatures.
Periodsofmoderatedisorderareapartoftheebbandflowofsoftwareevolution.Asamasterchef
toleratesamessykitchen,developersmustnotbeafraidtogetalittlemudontheirshoesastheyexplore
newterritoryforthefirsttime.Architecturalinsightisnottheproductofmasterplans,butofhardwon
experience.Thesoftwarearchitectsofyesteryearhadlittlechoiceotherthantoapplythelessonsthey
learnedinsuccessivedraftsoftheirsystems,sinceRECONSTRUCTIONwasoftentheonlypractical
meanstheyhadofsupplantingamediocresystemwithabetterone.Objects,frameworks,components,
andrefactoringtoolsprovideuswithanotheralternative.Objectspresentamediumforexpressingour
architecturalideasatalevelbetweencoarsegrainedapplicationsandcomponentsandlowlevelcode.
Refactoringtoolsandtechniquesfinallygiveusthemeanstocultivatetheseartifactsastheyevolve,and
capturetheseinsights.
TheoniondomedChurchoftheIntercessionoftheVirginontheMoatinMoscowisoneofRussia'smost
famouslandmarks.ItwasbuiltbyTsarIvanIVjustoutsideoftheKremlinwallsin1552to
commemorateRussia'svictoryovertheTatarsatKazan.Thechurchisbetterknownbyit'snickname,St.
Basil's.Ivantooisbetterknownbyhisnickname"IvantheTerrible".Legendhasitthatoncethe
cathedralwascompleted,Ivan,evertruetohisreputation,hadthearchitectsblinded,sothattheycould
neverbuildanythingmorebeautiful.Alas,thestateofsoftwarearchitecturetodayissuchthatfewofus
needfearforoureyesight.

http://www.laputan.org/mud/

30/36

1/6/2015

Big Ball of Mud

Acknowledgments
Alotofpeoplehavestriventohelpusavoidturningthispaperintoanunintentionalexampleofitscentral
theme.WearegratefulfirstofalltothemembersoftheUniversityofIllinoisSoftwareArchitecture
Group,JohnBrant,IanChai,RalphJohnson,LewisMuir,DragosManolescu,BrianMarick,EijiNabika,
John(Zhijiang)Han,KevinScheufele,TimRyan,GirishMaiya,WeerasakWittawaskul,Alejandra
Garrido,PeterHatch,andDonRoberts,whocommentedonseveraldraftsofthisworkoverthelastthree
years.
Wedliketoalsothankourtirelessshepherd,BobbyWoolf,whotrudgedthroughthemuckofseveral
earlierversionsofthispaper.
Naturally,wedliketoacknowledgethemembersofourPLoP97ConferenceWritersWorkshop,Norm
Kerth,HansRohnert,ClarkEvans,ShaiBenYehuda,LorraineBoyd,AlejandraGarrido,Dragos
Manolescu,GerardMeszaros,KyleBrown,RalphJohnson,andKlausRenzel.
LorrieBoydprovidedsomeparticularlypoignantobservationsonscale,andthehumancostofprojects
thatfail.
UIUCArchitectureprofessorBillRoseprovidedsomekeeninsightsonthedurabilityofhousingstock,
andhistoryoftheestrangementofarchitectsfrombuilders.
ThankstoBradAppleton,MichaelBeedle,RussHurlbut,andtherestofthepeopleintheChicago
PatternsGroupfortheirtime,suggestions,andruminationsonreuseandreincarnation.
ThankstoSteveBerczukandthemembersoftheBostonAreaPatternsGroupfortheirreview.
ThankstootoJoshuaKerievskyandtheDesignPatternsStudyGroupofNewYorkCityfortheir
comments.
We'dliketoexpressourgratitudeaswelltoPaoloCantoni,ChrisOlufson,SidWright,JohnLiu,Martin
Cohen,JohnPotter,RichardHelm,andJamesNobleoftheSydneyPatternsGroup,whoworkshopped
thispaperduringthelatewinter,er,summerofearly1998.
JohnVlissides,NeilHarrison,HansRohnert,JamesCoplien,andRalphJohnsonprovidedsome
particularlycandid,incisiveandusefulcriticismofsomeofthelaterdraftsofthepaper.
http://www.laputan.org/mud/

31/36

1/6/2015

Big Ball of Mud

Anumberofreadershaveobserved,overtheyears,thatBIGBALLOFMUDhasacertaindystopian,
Dilbertesquequalitytoit.WearegratefultoUnitedFeaturesSyndicate,Inc.fornothaving,asofyet,
askedustoremovethefollowingcartoonfromthewebbasedversionofBIGBALLOFMUD.

References
[Alexander 1964]
Christopher Alexander
Notes on the Synthesis of Form
Harvard University Press, Cambridge, MA, 1964
[Alexander 1979]
Christopher Alexander
The Timeless Way of Building
Oxford University Press, Oxford, UK, 1979
[Alexander et. al 1977]
C. Alexander, S. Ishikawa, and M. Silverstein
A Pattern Language
Oxford University Press, Oxford, UK, 1977
[Alexander 1988]
Christopher Alexander
The Oregon Experiment
Oxford University Press, Oxford, UK, 1988
[Bach 1997]
James Bach, Softwae Testing Labs
Good Enough Software: Beyond the Buzzword
IEEE Computer, August 1997
[Beck 1997]
Kent Beck
Smalltalk Best Practice Patterns
Prentice Hall, Upper Saddle River, NJ, 1997
[Beck & Cunningham 1989]
Kent Beck and Ward Cunningham
A Laboratory for Teaching Object-Oriented Thinking
OOPSLA '89 Proceedings
New Orleans, LA
October 1-6 1989, pages 1-6
[Beck 2000]
Kent Beck
Embracing Change: Extreme Programming Explained
Cambridge University Press, 2000
http://www.laputan.org/mud/

32/36

1/6/2015

Big Ball of Mud

[Booch 1994]
Grady Booch
Object-Oriented Analysis and Design with Applications
Benjamin/Cummings, Redwood City, CA, 1994
[Brand 1994]
Stewart Brand
How Buildings Learn: What Happens After They're Built
Viking Press, 1994
[Brooks 1995]
Frederick P. Brooks, Jr.
The Mythical Man-Month (Anniversary Edition)
Addison-Wesley, Boston, MA, 1995
[Brown et al. 1998]
William J. Brown, Raphael C. Malveau,
Hays W. "Skip" McCormick III, and Thomas J. Mobray
Antipatterns: Refactoring, Software Architectures, and Projects in Crisis
Wiley Computer Publishing, John Wiley & Sons, Inc., 1998
[Buschmann et al. 1996]
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stahl
Pattern-Oriented Software Architecture: A System of Patterns
John Wiley and Sons, 1996
[Coplien 1995]
James O. Coplien
A Generative Development-Process Pattern Language
First Conference on Pattern Languages of Programs (PLoP '94)
Monticello, Illinois, August 1994
Pattern Languages of Program Design
edited by James O. Coplien and Douglas C. Schmidt
Addison-Wesley, 1995
[Cunningham 1999a]
Ward Cunningham
Peter Principle of Programming
Portland Pattern Repository
13 August 1999
http://www.c2.com/cgi/wiki?PeterPrincipleProgramming
[Cunningham 1999b]
Ward Cunningham
The Most Complicated Thing that Could Possible Work
Portland Pattern Repository
13 August 1999
http://www.c2.com/cgi/wiki?TheMostComplexWhichCanBeMadeToWork
[Cusumano & Shelby 1995]
Michael A. Cusumano and Richard W. Shelby
Microsoft Secrets
The Free Press, New York, NY, 1995
[Foote 1988]
Brian Foote (Advisor: Ralph Johnson)
Designing to Facilitate Change with Object-Oriented Frameworks
Masters Thesis, 1988
Dept. of Computer Science,
University of Illinois at Urbana-Champaign
[Foote & Opdyke 1995]
Brian Foote and William F. Opdyke
Lifecycle and Refactoring Patterns that Support Evolution and Reuse
First Conference on Patterns Languages of Programs (PLoP '94)
Monticello, Illinois, August 1994
http://www.laputan.org/mud/

33/36

1/6/2015

Big Ball of Mud

Pattern Languages of Program Design

edited by James O. Coplien and Douglas C. Schmidt
Addison-Wesley, 1995
This volume is part of the Addison-Wesley Software Patterns Series.
[Foote & Yoder 1996]
Brian Foote and Joseph W. Yoder
Evolution, Architecture, and Metamorphosis
Second Conference on Patterns Languages of Programs (PLoP '95)
Monticello, Illinois, September 1995
Pattern Languages of Program Design 2
edited by John M. Vlissides, James O. Coplien, and Norman L. Kerth
Addison-Wesley, 1996
This volume is part of the Addison-Wesley Software Patterns Series.
[Foote & Roberts 1998]
Brian Foote and Don Roberts
Lingua Franca
Fifth Conference on Patterns Languages of Programs (PLoP '98)
Monticello, Illinois, August 1998
Technical Report #WUCS-98-25 (PLoP '98/EuroPLoP '98), September 1998
Department of Computer Science, Washington University
[Foote & Yoder 1996]
Brian Foote and Joseph W. Yoder
Evolution, Architecture, and Metamorphosis
Second Conference on Patterns Languages of Programs (PLoP '95)
Monticello, Illinois, September 1995
Pattern Languages of Program Design 2
edited by John M. Vlissides, James O. Coplien, and Norman L. Kerth
Addison-Wesley, 1996
This volume is part of the Addison-Wesley Software Patterns Series.
[Foote & Yoder 1998a]
Brian Foote and Joseph W. Yoder
The Selfish Class
Third Conference on Patterns Languages of Programs (PLoP '96)
Monticello, Illinois, September 1996
Technical Report #WUCS-97-07, September 1996
Department of Computer Science, Washington University
Pattern Languages of Program Design 3
edited by Robert Martin, Dirk Riehle, and Frank Buschmann
Addison-Wesley, 1998
http://www.laputan.org

This volume is part of the Addison-Wesley Software Patterns Series.

Brian also wrote an introduction for this volume.
[Foote & Yoder 1998b]
Brian Foote and Joseph W. Yoder
Metadata
Fifth Conference on Patterns Languages of Programs (PLoP '98)
Monticello, Illinois, August 1998
Technical Report #WUCS-98-25 (PLoP '98/EuroPLoP '98), September 1998
http://www.laputan.org/mud/

34/36

1/6/2015

Big Ball of Mud

Department of Computer Science, Washington University

[Fowler 1999]
Martin Fowler
Refactoring: Improving the Design of Existing Code
Addison Wesley Longman, 1999
[Gabriel 1991]
Richard P. Gabriel
Lisp: Good News Bad News and How to Win Big
http://www.laputan.org/gabriel/worse-is-better.html
[Gabriel 1996]
Richard P. Gabriel
Patterns of Software: Tales from the Software Community
Oxford University Press, Oxford, UK, 1996
http://www.oup-usa.org/
[Gamma et al. 1995]
Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides
Design Patterns: Elements of Reusable Object-Oriented Software
Addison-Wesley Longman, Reading, MA, 1995
[Garlan & Shaw 1993]
David Garlan and Mary Shaw
An Introduction to Software Architecture
V. Ambriola and G. Totora, editors
Advances in Software Engineering and Knowledge Engineering, Vol 2.
Singapore: World Scientific Publishing, 1993, pp. 1-39
[Ingalls 1983]
Daniel H. H. Ingalls
The Evolution of the Smalltalk Virtual Machine
Smalltalk-80: Bits of History, Words of Advice
edited by Glenn Krasner
Addison-Wesley, 1983
[Johnson & Foote 1988]
Ralph Johnson and Brian Foote
Designing Reusable Classes
Journal of Object-Oriented Programming
Volume 1, Number 2, June/July 1988
[Marick 1995]
Brian Marick
The Craft of Software Testing
Prentice-Hall, Upper Saddle River, NJ, 1995
[Meszaros 1997]
Gerard Meszaros
Archi-Patterns: A Process Pattern Language for Defining Architectures
Fourth Conference on Pattern Languages of Programs (PLoP '97)
Monticello, Illinois, September 1997
[Roberts & Johnson 1998]
Don Roberts and Ralph E. Johnson
Evolve Frameworks into Domain-Specific Languages
Third Conference on Patterns Languages of Programs (PLoP '96)
Monticello, Illinois, September 1996
Technical Report #WUCS-97-07, September 1996
Department of Computer Science, Washington University
Pattern Languages of Program Design 3
edited by Robert Martin, Dirk Riehle, and Frank Buschmann
Addison-Wesley, 1998
[Shaw 1996]
Mary Shaw
http://www.laputan.org/mud/

35/36

1/6/2015

Big Ball of Mud

Some Patterns for Software Architectures

Second Conference on Patterns Languages of Programs (PLoP '95)
Monticello, Illinois, September 1995
Pattern Languages of Program Design 2
edited by John M. Vlissides, James O. Coplien, and Norman L. Kerth
Addison-Wesley, 1996
[Simon 1969]
Herbert A. Simon
The Sciences of the Artificial
MIT Press, Cambridge, MA, 1969
[Swift 1726]
Johnathan Swift
Travels Into Several Remote Nations Of The World.
In four parts. By Lemuel Gulliver, First a Surgeon, and then a Captain of several Ships.
B. Motte, London, 1726.
[Vitruvius 20 B.C.]
Marcus Vitruvius Pollio (60 B.C-20 B.C.)
De Architectura
translated by Joseph Gwilt
Priestley and Weale, London, 1826

BrianFootefoote@laputan.org
LastModified:21November2012

http://www.laputan.org/mud/

36/36