ShouldWeStopWritingPatterns? 1

Shouldwestopwritingdesignpatterns?RebeccaWirfs-Brock,Wirfs-BrockAssociatesThisessayreflectsonexperiencesI’vehadandwhatI’velearnedoverthepast15yearsofwritingsoftwaredesignpatterns.I’vecometobelievethatifwewanttobroadlyincreasepatternliteracy,relevancy,andlong-termimpact,somethingsneedtochange.Mostimportantly,Ibelievethatchangeneedstostartwithpatternwriters,likeme.InsteadofindiscriminatelywritingevenmorepatternsIshouldfocusmoreonconnecting,relating,promoting,andrefreshingexistingimpactfulpatterns.Changesalsoneedtobemadeinhowourcommunityoflong-timepatternauthorsandadvocatespresent,organize,andpromotepatternstotherestoftheworld.

DesignPatterns,ProcessPatterns,andLearningfromWritingPatternsI’vewrittendozensofpatternswithseveralcolleaguesandfriends.Thetopicsrangefromsoftwarerequirementstosoftwaredesignandarchitecturetosoftwaredevelopmentprocessandpracticepatterns.Someofourpatternshavebeentechnical,detailedpatternsforaspecificarchitecturestyle(specifically,AdaptiveObjectModels)[AHLSWY,WWY07,WYW08,WYW09,HNSWY10,HLNSWY10].OthershavebeenaboutarchitecturepracticesonAgileprojects[WY,WYG].Stillothershavebeenaboutpatternsforimprovingsoftwarequality[YWA2014,YWW2014a,YWW2014b,YWW2015,YWW2016a,YWW2016b].I’veevenventuredtowritepatternsaboutmanagingandevolvingmeaningfulproductbacklogsforcomplex,long-livedengineeringproducts[Hva2015,Wirf2016,Hva2017,Hva2018,Wirf2019].Thedisciplineofwritingpatternshasbeenmostlyfunandonlyoccasionallychallenging.Surprisingly,oneofthemostdifficultaspectsofwritingpatternshasbeengettingsufficientlyrichandusefulcritiquesfrompatternwritingworkshops.Sometimesmyfellowwritingworkshopcolleagueshavebeenhelpful,atothertimesthey’vebarelygraspedmypatterns.ThisismostlybecausePLoPconferenceshavebecomevenuesforreviewingmanymorekindsofpatternsthanthosefordesigning,building,andmanagingsoftwaredevelopmentproductsandprojects.Notmanyexperienceddesignersandarchitectsattendpatternwritingconferencesthesedays.Sothesedays,mostofmyexposuretonewdesignideasandinspirationcomesfromoutsidethepatternscommunity.Throughmypatternwriting,I’veimmersedmyselfinpatterntriviaandbecomeastudentofpatternsandChristopherAlexander’swritingsandphilosophy.Andyet,Istillfeellikeanpatternscommunityoutsider.InsidethepatternscommunityImay

ShouldWeStopWritingPatterns? 2

beperceivedassomewhatofapatterngeek;outsidethiscommunityItalkwithmanyotherdevelopersanddesignersabouttheirpracticesandtechniques,anddesignguidelinesandheuristicsandsuccessesandfailures.OnlyoccasionallydoItalktothemaboutpatterns.Therearebenefitstobeinganoutsider.IfeelanoutsidertoanycommunityIampartof,bytheway.Thisfeelingisn’tuniquetopatterns.ThefactthatIdon’tfeelthatIamsingularlydefinedbyanyparticularcommunityallowsmetomovebetweencommunitiesandspreadandlearnnewideas.ThismeansthatI’mnotdefinedbypatternwriting.NoramIdefinedbyDomainDrivenDesign,Agiledevelopment,architecture,orOpenSpacecommunities.WhatIdocaremostabout,andthistranscendscommunities,isaboutlearningandsharingexpertiseandgrowingawarenessinandappreciationinothersabouthowtosustainablydesignandbuildusefulsoftwaresystems.NoneofthepatternsIhavewrittenhavehadmuch,ifany,impactonthislargersoftwaredevelopmentcommunity.Coulditbethatweinthepatternscommunityareoperatingatametalevelofsoftwaredevelopmentwhilemostdevelopersareinterestedinmoreconcreteproblemsandmorespecific,detailedadvice?Orperhapsitwasamatterofpackaging.Somepatternswewrotewerepartofpatternscollections.ButtheywerescatteredoveraseriesofpaperspublishedoverseveralyearsindifferentPLoPproceedings.Thismakesitdifficultforallbutthemostdedicatedreadertofind.Forvariousreasonswehavenotyetpublishedthesepatternsinbookswhichperhapswouldhavemadeourpatternsmoreaccesible.Isuspectthatotherfactorscontributedtoourpatterns’obscurityaswell—amatterofpoortiming,lackofapproachabilityofwrittenpatternformstomytargetedaudience,limitedapplicability,lackofpromotion,orlackofanydeepandlastingconnectionsbetweenourpatternsandotherdesignpracticesandpatternsandschoolsofthought.Myobjectdesignbooks[Wirf90,Wirf02]havehadafargreaterimpactondesigners.Thisispartduetothereadability/approachabilityofthebooks,butalsopartlyduetotiming.AlthoughIthinkmysecondbookonobjectdesignhadevenmorevaluablecontributionstodesignthinking,itisthefirstbookwrittenin1990thatwas(andstillis)morewidelyrecognizedandnoticed.Regardless,writingthesepatternshashadatremendousimpactonme.SomelessonsI’velearned:

Manyexistingsoftwaredesignandarchitectpatternsareofinterestonlytothoseworkinginanarrowsoftwareniche.Toilingawaywritingaboutavariantofaparticularpatternmayaddtoouroverallbodyofknowledge(yes,IwroteapatternnamedAdaptiveObjectModelBuilder

ShouldWeStopWritingPatterns? 3

[WYW09],avariantoftheBuilderpattern,andseveralAdaptiveObjectModelrenderingpatterns,butthiseffortwasoflimitedvalue.Suchknowledge(especiallysinceitisextremelynarrow)canbeofvalueonlyifthatknowledgecanbereadilysharedandmadeaccessibletoothersworkinginthatsamesoftwaredesignspace.Notmanyarebuildingadaptiveobject-modelarchitectures.Inhindsight,Icautionpotentialauthorswhoareworkinginaspecializedsoftwarefield,tobeaware—theeffortyoutaketodocumentyourworkaspatternsmaynothaveanydiscernibleeffecttoadvancingyourfield.Patternwritingcanhelpyouunderstandanddevelopyourcontribution.You’lllearnhowtoexpressthedesignconstraintsandforcesthatarebalancedbyaparticularpattern.You’lllearnhowtocreateandillustrateexemplarysolutions.Butthedarkertruthisthatpublishingyourknowledgeonlyinpatternformmostlikelylimitstheexposureofyourworktoonlythosefewwhoareengagedinwritingpatternscommunity.

Manysoftwarepatterndescriptionsneedrefreshing.Thisisespeciallytrueofmanyearlysoftwaredesign“proto-patterns.”ChristopherAlexanderandcolleaguesintheprefacetoAPatternLanguageobserved:“...eachpatternrepresentsourcurrentbestguessastowhatarrangementofthephysicalenvironmentwillworktosolvetheproblempresented.Theempiricalquestionscenterontheproblem—doesitoccurandisitfeltinthewaywedescribeit?—andthesolution—doesthearrangementweproposesolvetheproblem?Andtheasterisksrepresentourdegreeoffaithinthesehypotheses.Butofcourse,nomatterwhattheasteriskssay,thepatternsarestillhypotheses,all253ofthem—andare,therefore,alltentative,allfreetoevolveundertheimpactofnewexperienceandobservation.”Alexanderexpectedtheirpatternstoevolveundernewsituationsanddesigncontexts.Whathisexpectationsforhowthesenewinsightscouldbeconveyedtootherdesignersandarchitectsandbuildersisn’tsoclear.InlaterworksAlexanderspeaksofcreatingproject-specificpatternlanguages(addingtoandemphasizingpartiularpatterns)thatwouldprovidehighlevelguidanceforaspecificarchitectureproject.Projectlanguagesconsistofuniqueandcustomizedsetsofpatterns,appropriatetoaspecificcontext.Wesoftwaredesignersandarchitectshavethechallenge—orratheranopportunity—toillustrateandshareourdesigninsightsmorereadily.Eventhoughmanyearlypatternsauthorshavenotupdatedtheirwell-knownpatterndescriptions,otherswithunclearconnectionstotheoriginalauthorsorthePloPcomunity,areadmirablytakingupthiseffort.Foronegoodexample,JohnThompsonofferswebpagesthatgiveanupdatedpresentationofthe23patternsinDesignPatternscastintermsoftheJavaSpringFramework[Thom].Thesedescriptionsarewell-motivatedandprovideaquiteapproachableintroductionforJavaprogrammers.TheObserverpatterndescription

ShouldWeStopWritingPatterns? 4

hasbeenmotivatedbyamoremodernapplication(registeringandreceivingtweetsfromthoseyoufollow).AndtheexamplesolutionusesJavainterfacesinsteadoftheoriginalclass-basedsolutionstodefineObeserverandSubjectbehaviors.Andtomakethepatternevenmorerelevant,aspecificexampleofhowthispatternisappliedintheSpringFrameworkisillustrated.TheauthoralsowritesaverygooddiscussionofthecontroversialSingletonpattern,demonstratinghowtocreateathreadsafeversionofaSingletonandofferingstronglywordedopinionsonwhereitmightbeappropriatelyandwhyitshouldbesparinglyused.AnotherexampleisBrandonRhodes’Pythonpatternsguidewebsite[Rhod].InadditiontoshowingexamplesofeachGOFpattern,healsopresentsadditionalcommonPythonpatternsanddiscussesatlengthhowbyusingthedeisgnprinciplesinDesignPatternsonecancometoarobust,comprehensiveandflexibledesignsolution.Forexample,inthediscussionoftheprinciple,favorcompositionoverinheritance,differentdesignsolutionstologgingareshownanddiscussed.TheserangefromAdaptertoBridgeandDecoratorpatternimplementations.Then,inasectiontitled“GoingbeyondtheGangofFourpatterns”heillustrateshowthePython’sloggingcapabilitiesimplementedintheStandardLibraryimplementedevenmoreflexibility:notonlysupportingmultiplefilters,butmultipleoutputstreamsforlogmessages.ThesetwositesprovidequiteusefulinformationforthedesigncuriousJavaorPythonprogrammersatthelevelofdetailthatprogrammerscanrelateto,withplentyofcodealongwiththoughtfuldesigndiscussionandcommentary.1

Manyotherpatternsarebroadlyuseful,eveniftheyarenotwellknown.Anotableexampleofusefulpatternsthathaveslippedintorelativeobscurityarethesoftwarere-engineeringpatternsdescribedinObject-OrientedSoftwareReengineeringPatterns bySergeDemeyer,StéphaneDucasse,andOscarNierstrasz[Dem].Recentlytheauthorshavereclaimedthecopyrighttothisbookandnowhavemadeanonlineversionfreelyavailable.2

1ItisinterestingtonotethattheauthorsoftheserefreshedDesignPatternsonlyshowcodesolutions;noneoftheirpatternsareillustratedwithUMLclassorsequencediagrams.2ThecurrentpackagingofthesepatternsisnowavailableasanOpenTextbookLibrarytext.Seehttps://open.umn.edu/opentextbooks/textbooks/object-oriented-

2ThecurrentpackagingofthesepatternsisnowavailableasanOpenTextbookLibrarytext.Seehttps://open.umn.edu/opentextbooks/textbooks/object-oriented-reengineering-patternswithaccesswithattributionlicensing.

ShouldWeStopWritingPatterns? 5

Eachchapterstartswithapatternmapillustratingpotentialsequencesthroughthepatternsthechapterbasedonactions(forexample,seeFigure1forthepatternmapforChapter4).

Figure1.EachchapterinObject-OrientedReengineeringPatternsisasmalllanguage

Manyofthesepatternsarestillrelevantintoday’sdevelopmentcontext(althoughtheytoo,couldbenefitfromsomeupdates.Forexample,oneofthepatternsisDoaMockInstallation.Thesedays,thebuildprocess,evenforalegacysystem,typicallyhasbeenatleastpartiallyautomated;consequentlyanappropriatesubstituteforthismightbeapatternnamedBuildtheSystemandMapDependencies).InapreviousessayIobserved[Wirf]that,“Unintentionally,thebiggestmissteptheseauthorsmadewastitlingtheirbook,Object-OrientedReengineeringPatterns.”Objecttechnologypatternsareonlymentionedinthelasttwochapters,andsomeoftheseobject-technologyspecificpatternscouldeasilyberewrittentobemoregenerallyapplicableinbothfunctionalandobjectprogrammingimplementations:MoveBehaviorClosetoData,EliminateNavigationCode,FactoroutState,andFactoroutStrategy.PerhapsifretitledSoftwareReengineeringPatterns(andnewadditionalchaptersdescribedseveralfunctionalprogramminglanguageimplementationpatterns)thesepatternscouldberescuedfromobscurity.Anotherexampleofahandfulofusefulbutunknownpatternscomesfrommyownwork.Ina2008patternpaper[WY]IwrotewithJoeYoder,descriptionsofthreepatternsforsustainingsoftwarearchitecture.Joe,amongotheraccomplishments,isknownasoneoftheco-authorsoftheBigBallofMudpattern[Foot],arguablyoneofthemostmisunderstoodpatternsofalltime.3PavingOverTheWagonTrailisapatternforbuildingatool(mostlikelytogeneratecode)thatallowsrepetitive,error3PeopleoftenrefertotheBigBallofMudasananti-pattern,anarchitecturethatissprawlingandunmaintainable,thatyoushouldtrytore-work.Instead,theBigBallofMudpapercontainsanumberofsmallerpracticalpatternsforcontainingandmanagingcomplexityinasprawlinglegacysysteminadditiontoitsheart-feltandhumorousdiscussionofhowitisbettertolivewithmud(inappropriateplacesofasystem)ratherthantotrytofixthingsupandmakeatotallynew,cleanarchitecture.

Chapter 4: Initial Understanding Patterns

Identify problems

Understand?

Top Down

Pattern 4.1: Analyze the Persistent Data

Pattern 4.2 Speculate about Design

Bottom up

Pattern 4:3 Study the Exceptional Entities

Recover design

Recover database

ShouldWeStopWritingPatterns? 6

proneprogrammingtaskstobeeliminated.WipingYourFeetattheDoorisapatternforcleaningupdata/transformingitatthe“edges”ofasysteminordertoreduceinternalcomplexity.Thethirdpatternwasawell-intentionedefforttomakeprogrammingsimplerthatinsteadreinforcedpoorprogrammingpracticesandexacerbatedtheerosionofthearchitecture,PavingovertheCowpath.Inthispatternwetookcaretoexplainwhythisisnotananti-pattern,butinsteadadarkerformofwellintentionedtooltinkering.Thesepatternshelpwithbothpreventionofdesigndecayandsustainingcomplex,evolvingarchitectures. Arguablythesepatternsarerelevanttoday,butastheynevergainedmuchvisibilitytheyareatanevenhigherriskoffadingintoobscurity.PerhapsIamhumoringmyselfthinkingthattheyhaven’talreadydisappearedfromsight.Isuspectthereareseveralreasonsfortheirobscurity.Wewerefartoocleverandculturallylimitingwiththeirnaming.TheBigBallofMudafterall,inspiredus,togivethemnamesthatimpliedmuddypathways,andtrails,andtheneedtocleandataatsystementryways.Thisdetractedfromourpatterns’potential“stickiness.”Perhapsamoreimportantcontributiontotheirobscurity,Isuspect,wasthatwedidnotactivelyconnectthemtootherwell-knownrelatedpatternssuchasEricEvan’sAntiCorruptionLayerpatterns[Evan]orBigBallofMudPatterns.Wecertainlyknewaboutthesepatterns,butweweremoreinterestedinwritingaboutnewpatternswhichincorporatedoursharedknowledgeandexperiencethaninhookingthemtothebroaderbodyofexistingpatternsandpromotingtheirrecognitionanduse.4 Patterns,nomatterhowuseful,cannotnotsurviveinisolation.ImaginehavingjustreadAPL’sWindowPlaceorLightonTwoSidespatternwithouthavingalargercontextofdesigningadwellingasdescribedinthepatternaHouseforaSmallFamilyoraBuildingComplex.Notonlyshouldpatternsbeconnected;therenaturallyarelarger“enclosing”patternsthatshouldbeidentifiedwhichprovideahomeforandstructureforpatternswithasmallerscope.Tostayrelevant,goodsoftwaredesignpatternsneedtobeconnectedtoother,relatedpatternsandheuristicsandpractices(regardlessofwhoauthoredthem).Andtheyshouldn’tbecastastoocleverorculturallyquaint.

Manysoftwaredesignandarchitecturepatterndescriptions,areoverlyspecificandimplyprescriptivetechnologysolutions.ItiseasytocriticizetheoriginalDesignPatternsdescriptionsasof2020asbeingoutdated.Butthisisn’tafaircritique.Atthetimeearlypatternauthorswrotetheirpatterns,theydescribedwhattheyknewanddirectlyexperienced.Nospeculationorinnovationorgeneralization;designpatternsdescribeddesignphenomena4Perhapsthisurgetocreateratherthanintegrateshouldn’tbesurprising,butneithertheBigBallofMudnorDomainDrivenDesignpatternshavebeenupdatedbytheiroriginalauthors.Fortunately,otherthoughtleadersintheDDDcommunityhavewrittenseveralbookspopularizingseveralcomplementaryDomainDrivenDesignpracticesandpatterns.

ShouldWeStopWritingPatterns? 7

observedinmultiple,pre-existing,successfulsoftwaresystems.DesignPatternswaswrittenwhenobject-technologywasgainingprominanceandobjectdesignsolutionswerecommon(theystillare,butarenotaspredominant).EventheSpringFrameworkdesignpatternsauthorgivesasomewhatlimitedviewofthesepatterns’utilityasevidencedbytheirintroductiontohiswork:“TheGoFwrotethebookinaC++contextbutitstillremainsveryrelevanttoJavaprogramming.C++andJavaarebothobject-orientedlanguages.TheGoFauthors,throughtheirexperienceincodinglarge-scaleenterprisesystemsusingC++,sawcommonpatternsemerge.ThesedesignpatternsarenotuniquetoC++.Thedesignpatternscanbeappliedinanyobjectorientedlanguage.”5However,thereisnothingobjecttechnolgoyspecificaboutanAdapteroraFacadeoranObservereventhoughDesignPatternswasexplicitlywrittenasacollectionofObjectDesignsolutionpatternsillustratedwithpre-UMLclassdiagramsandC++codesnippets.Eventoday,mostdevelopersconstruetheoriginal23DesignPatternsaspatternsasrelevantonlytoobject-orientedsoftwaresolutions.However,itisstraightforwardformetotransposethesepatternstodifferentcontexts.IknowIcanemployanAdapterorBridgeorStrategyregardlessoftechnology.Amoreinexperienceddesignerdoesnotmaketheseconnectionssoeasily.Assomeonewhohasdesignedsoftwarefordecades,Icanseeandsubsequentlyabstractpatternsolutionsinordertore-applythemtonewtechnologieseventhoughtheoriginalpatterndescriptionsmighthavebeenoverlyconstrainedordeceptivelysimplified.ItisalsointerestingtonotethattheSpringJavarefreshedversionsofDesignPatternsincludeexampleswritteninJava,alongwithtextualdescriptions.TherearenoClassdiagramillustrationsormoreabstractdepictionsofpatternsolutions.Thesedays,evenamoreabstractrepresentationofadesignsolution—sayaUMLclassorsequencediagramfragment—isbecomingincreasinglyrarebecausesuchrepresentationsareunknowableandincomprehensibletomostprogrammers.ThefactthatI’vehaddirectexperiencemakingaswellasseeingpatternsolutionsimplementedinseveraldifferentprogramminglanguagesgivesmeaperspectivethatislackinginsomeonewithonlyJavaprogrammingexperience.ExperiencedJavadeveloperswhohaveseensoftwarepatternsimplementedonlyinJavaonlyknowtheminthatcontext.Paradoxically,thislimitstheirdesignreach;whileatthesametimestrengthenstheirJavaprogrammingefficacy.

5Infact,theauthorsofDesignPatternswerefamiliarwithC++andSmalltalk.ButasSmalltalk’spopularitywasfadingatthetimethebookwaswritten,theymadethedecisiontouseoneprogramminglanguageandtheychoseC++.

ShouldWeStopWritingPatterns? 8

There’sanunresolvabletensionbetweenpresentingeasilyunderstoodconcretesolutionsandmoregeneralizableabstractionsHoweverusefulsoftwaredesignpatternsmaybe,unlesstheyhavebeenrefreshedandcontextualizedfortoday’stechnologiesandsoftwaredesigners,theywillbedifficultfornewcomerstograsp.Anaccessibleintroductiontoaspecificsoftwarepatternanditssignificanceideallyprovidesacontextandaconcreteexamplethatcanbereadilylatchedonto.Whenthetechnologychanges—tostayapproachable—thatsolutionwillmostlikelyneedupdating.Paradoxically,itistheconcretenessofapatternsolutionthatdeceivesusintobelievingthat“whatweseeisallthereis”[Kahn].AsRudolphArnheiminVisualThinking[Arn]observes,“Themoreperfectourmeansofdirectexperience,themoreeasilywearecaughtbythedangerousillusionthatperceivingistantamounttoknowingandunderstanding.”Topresenttheessenceofapattern,however,requiresadifferentangle.Thatformneedsasparserdescriptionwithasimple,exemplarysketchoftheproblemandsolution.Itneedstoconveyitssignificanceandatthesametimeenableustoadaptittoourspecificdesignsituation.Equallyimportant,thatpatternneedstobelocatedamongotherpatternsandwithinalargerdesigncontext.Bothkindsofdescriptionsarevaluable—justtodifferentaudiences.Todatewehaven’tidentifiedwaysto“label”ourpatternsdescriptionswithcautionaryadvice.Sowepatternauthorsneedtobecarefulaswechoosetorepresentsolutionstotakecaretoexplainourchoicestoourreaders.

BacktomyPatternsBeginningsLooking back to 2006, IwrotemyfirstpatternswithPaulTaylorandJamesNoble[WTN].Weexploredwritingpatternsforconceptualizingproblemsratherthandesigningsolutionstothoseproblems.Wewereeagertomakeconnections(andcreateorlinkarichnetworkofpatterns)thatspannedrequirementsanddesign.Therearetimeswhensoftwaredesignersdon’tseeclearlythewhattheproblemis.Inourpaperweasked,“Whatifwefindourselveswashingaroundintheamorphousproblemspace,unabletogetafootholdonanythingtobeartheweightofa[design]patternortoanchorafragmentofarchitecture?Isthereanotherkindofpatternthathelpstolocateourthinkingearlyintheanalysisandconceptualizationofsystemsandsolutions?Dopatternsintheproblemspaceexist?”WeusedMichaelJackson’sProblemFrames[Jack]asabasisforthispatternwritingexperiment.Jackson’sproblemframesareintriguingbecausetheybuildonarecognitionofgenericproblemtypes,basedonstructuresandrelationships

ShouldWeStopWritingPatterns? 9

betweendomainsanddesignedsystemelements(Jacksoncallsthese“machines”).Problemframesarebasedonthephilosophyofphenomenology,whichfirmlyplacesusinaworldofconcepts,domains,phenomenaandmachines—inourcaseassoftwaredesginersthosemachinesaresoftwaremechanismsofourowndesign—whichinteractwiththeelementsoftheproblem’senvelopingcontextinordertohaveadesiredeffectupontheworld.Jacksondescribedfivedifferentproblemframes:RequiredBehavior,CommandedBehavior,InformationDisplay,SimpleWorkpieces,andTransformation.Letmebrieflycharacterizeeachframe.ARequiredbehaviorframedealswithaclassofproblemswhereyouwanttocontrolstatechangesofsomethingoutsidetheboundariesofyoursoftwaremachinery.ACommandedBehaviorproblemframeisaboutcontrollingchangestosomethingbasedoneitheranoperatororuser’scommands.Aninformationframeisaboutproblemswherethereisaneedtoproduceinformationaboutobservablephenomena(usuallyovertime).ASimpleWorkpiecesFrameaddressestheproblemofcreatingtooling,whichenablesuserstocreateandmanipulatestructures.Finally,aTransformationframeisaboutproblemsofconvertinginputtooneormoreoutputs.Jacksonillustratedeachproblemframewithaschematicdrawinganddiscussedtheirspecificconcerns.IrecallthatwhenfirstingreadJackson’sworksomeyearspriortomypatternwritingexperiment,thatIhopedadditionalframeswouldsoonbeaddedbyanactiveproblemframingcommunity.6TheproblemframesJacksondescribed,oratleastthewaytheywerepresentedinhisbook,didn’tseemimmediatelyrelevanttotheproblemsIfrequentlyencounteredinITandsoftwareengineering.Jackson’sframesseemedmostappropriateforcharacterizingrequirementsofphysicalcontrolsystems.However,IfoundthatwithalittlebitofmentaleffortthatIcould“stretch”hisconceptualframeworktofitintotheITandengineeringproblemsIwasdesigningsolutionsfor.Forexample,insteadofcontrollingadevice,Imightdesignsoftwarethatwas“controlling”thebehaviorofanexternalsoftwaresystemthatIcouldn’tdirectlyprobeforwhetherithadactedonmysoftware’srequests.IwasmodernizingandrefreshingJackson’sframestobetterfitmydesigncontext.ButIcouldonlystretchhisframessofarandtheyonlycoveredsomuchofmyproblemterritory.6IrememberwhenIfirstreviewedtheDesignPatternsbook[Gamm]thatIhopedformorepatterns,too.Infact,inmyreviewofthedraftofthebooktoAddison-WesleyIsuggestedthattheypublishthebookinaformwhereinstallmentsandadditionscouldbemadeonaregularbasis.ThisnotionwassimilarinconcepttotheyearlyaddendumtotheEncyclopediaBritannica,whichcouldbepurchasedannuallytokeeptheencyclopediauptodate.

ShouldWeStopWritingPatterns? 10

OnceIconceptuallyunderstoodproblemframes,Icaughtglimpsesofthemeverywhere.Complexsoftwaresystemsandsystemsinteractingwithothersystemsanddatabasestendtohavemultipleoverlappingframes.SoafterIhadappropriatelyframedasituation,thereweresalientquestionsIcouldasktouncovermoreinformationaboutthenatureoftheproblemathand.Forexample,herearesomequestionstoaskaboutrequiredbehaviorproblems:

• Whatexternalstatemustbecontrolled?• Howdoesmysoftwarefindoutwhetheritsactionshavehadtheintended

effect?Doesitneedtoknowforcertain,orcanitjustreactlater(whenthestateofsomethingisnotasexpected)?

• Whatshouldhappenwhenthingsget“outofsynch”betweenthesoftwaresystemandthethingitissupposedlycontrolling?

• Howandwhendoesmysoftwaredecidewhatactionstoinitiate?• Isthereasequencetotheseactions?Dotheydependoneachother?• Aretherecomplexinteractionswithmysoftwareandthethingunderits

control?Shouldtherebe?• CanIviewtheconnectionbetweenmysoftwareandthethingundercontrol

asbeingdirect(easier)ordoIneedtoconsiderthatitisconnectedtosomethingthattransmitsrequeststothethingbeingcontrolled(andthatthisconnectioncancausequirky,interestingbehavior)?Ifso,thenImayneedtounderstandmoreaboutthepropertiesofthis“connectiondomain”thatstandsbetweenmysoftwareandthethingbeingcontrolled.

Inourproblemframepatternspaperweremarkedthat,“[t]hefactthatweputproblemframesintopatternformdemonstratesthatwhenpeoplewritespecifications,theyaredesigningtoo—theyaredesigningtheoverallsystem,notitsinternalstructure.”Andwhileproblemframesarefirmlyrootedintheproblemspace,toustheyalsosuggestedpotentialpatternsolutionspacestoexplore.Forexamplewhensolvingtranslationproblemsitseemsreasonabletocheckoutsoftwaredesignpatternsabouthowtowriteparsers,ortoconsidertheCommandpatternwhendesigningasolutiontoaCommandedBehaviorproblem(ormostframesinvolvingauser-operatordomain).AndRequiredBehaviorproblemssuggestinvestigatingeventandeventhandlingpatterns,finitestatemachines,orreactivesystemdesignpatterns.Thesearefairlystraightforwardconnectionsformeasanexperiencedsoftwaredesignertomake.ButthisisbecauseIknowofmanysoftwaredesignandarchitecturepatternsaswellasotherdesigntechniques,practices,architecturestyles,anddesignheuristics.Problemframingissimplyone,amongmanyways,toexploreaproblemspace—aconceptualtoolIusetofocusasIuntanglecomplexsystemrequirements.AtthattimeIlearnedaboutproblemframes,therewereotherbetter-knownanalytictechniquesavailable.WeanalystsanddesignerswerebusywritingUseCases,creatingcontextdiagrams,workflow,dataandobjectdiagrams.Iintegrated

ShouldWeStopWritingPatterns? 11

framingintomyexistingbagoftricksforunderstandingtheproblemspaceandquietlymovedon.Problemframingdidn’treplaceanyanalysistechniqueIalreadyknew;itjustslippedinamongstthemallasanimperfectbackdrop.So,didproblemframinghelpmebeabetterdesigner?I’mnotsure.Thepathfromframingaproblemtochoosinganappropriatesoftwarearchitectureorsetofdesignpatternsisroundaboutatbest.Weremarkedinourpaperthat,“Patternsworklikealadderinthe‘SnakesandLadders’boardgame—givenaknowncontextandproblem(squareontheboard)theygiveusaleg-uptoahigherplace.Designpatternsfallsquarelyinthemiddleofthesolutionspaceandprovideobject-orientedfragments7ofstructuretoresolvesolutionspaceforces.”Whilesoftwaredesignpatternsareaboutdesigningthings,therearealsopatternsintheproblemspace,too.Onceyou“see”them,applyingthelensofaparticularframeleadsyoutoaskfocusedquestionsaboutasoftwaresystem’srequirements.Butthat’saboutit.Theanswerstothesequestionsdon’tdirectlyleadyoutospecificdesignpatternsandapproaches;theysimplyraiseyourawarenessofwhatmightbetheharderproblemstosolve.Didproblemframinghelpothersbebetteranalysts?Ingeneral,I’dsayno.Ifoundteachingothersaboutproblemframestobeanabjectfailure.Problemframesconfusedmystudents.Afterafewfailedattemptsattryingtogetthemtoappreciateproblemframesinalltheirgorydetail—howtoidentifythem,drawthem,anddescribetheirconcerns,Idroppedtheideaofexplicitlyteachingthementirely.Theydidn’tseethepoint.Theydid,however,finditusefultohavesetsofrelatedquestionstheycouldaskinordertogainfurtherinsightintotheirsystem’srequirements.Thatthosequestionswererelatedtothespecificconcernsrelevanttoeachproblemframewasadistraction.But,shh!!Noneedtotellmystudentsaboutproblemframes.Learningthemechanicsofwritingclearlyandattheappropriatelevelofdetail(andsomequestionstheymightasktogetatthosedetails)werepracticalskillsthattheycouldabsorbandappreciate.Theconceptualbackdropofproblemframingwasunnecessary.

7Toputthisinhistoricalcontext,wewereawashinobjecttechnology,design,andarchitecturepatternsasof2006:DesignPatternshadbeenpublishedwithgreatsuccessfollowedbyFowler’sAnalysisPatterns(1996),PatternsofEnterpriseApplicationArchitectureandObject-orientedReengineeringPatternsin(2002),DomainDrivenDesign(2003),andthreeofthefivevolumesofPattern-OrientedSoftwareArchitecture.

ShouldWeStopWritingPatterns? 12

Framingissimplyonewaytogainsomedesignperspective—regardlessofwhetherIcandirectlyemploythoseinsightsintopatterneddesignsolutions.

SomeConclusionsandaCalltoActionAsdesignersandarchitectswewouldlikeittobestraightforwardtolinkproblemstopotentialsolutions.ButIfindittakesalotofhardwork,experimentation,andthinkingbeforeIprocedetodesignwithconfidence.Anddespiteknowingmany,manypatterns,Irecognizetheytooonlyoffergeneraloutlinesofpotentialapproaches.Istillhavetofillinmanydetailsandmakedecisionsaboutmydesignunaidedbypatterns.Andyet,Istillhavefaithinsoftwaredesignpatternsandwishtheyweremorereadilyavailableandmoreuseful.Overtime,theexistingbodyofsoftwaredesignpatternshasbecomesprawling,disorganized,outdated,andunknownorundervaluedbymanysoftwaredevelopers.Ifweasapatternscommunitywanttopromotesoftwaredesignpatternliteracy,relevancy,andlong-termimpact,somethingneedstochange.Tobroadenoureffortsperhapsweshouldperformsomeboldexperiments:Newlypublishedpatternsareonlyinfrequentlylocatedandanchoredtotheexistingsoftwarepatternlandscape.Consequently,thereislittlecoherencetothelargebodyofexistingsoftwarepatterns.Maybetheexistingbodyofsoftwarepatternsistoosprawlingtoputbacktogetherinanycoherentway.Butwewon’tknowuntilwetry.Insteadofonlyholdingpatternsconferenceswhosefocusistoencouragenewauthorsandstudentstowriteyetmorepatterns;couldweturnourattentiontowardorganizing,updating,re-mining,promoting,connectingandre-connecting,andrescuingtheexistingbodyofexistingpatterns?Perhapsnow,wecouldstartavirtualefforttoorganizeanddiscussandpromotepatterns.Weinthepatternscommunityhaveauniqueperspectivethatcouldhelpweavetogethersomedisjointsoftwarepatternsaswellasconsolidatethe“core,”moretimelessdesignpatternsfromwhichotherdesignerscandrawupon.Wehaveagoldenopportunitytoshareandrecommendwhatwefindtobethemostimportantpatternsandpracticesforcreatingsustainablesoftware.Wecouldcreatealsocreateaforumfordesignerstosharetheirinsightsintothemanydetaileddecisionstheyencounterastheyimplementthesepatternsandthegapstheyseeinourpatternedknowledge.Maybeinsteadofonlyhavingpatternwritingconferencesweneedtostartholdingvirtualsoftwarepatternmining,designheuristichunting,andrefiningevents.Andperhaps,weshouldstartpubishingpatternsdifferently.Wecoulddesignateoneormorecommentatorstowriteanaccompanyingprecisaswellananalysisthat

ShouldWeStopWritingPatterns? 13

connectsthesenewlywrittenpatternstothepre-existingbodyofknowledge.Andwecouldevenbesoboldastospeculateonthosenewpatterns’significanceandutility.So,isittimewestopwritingpatterns?Ofcourse,not.Notentirely.ButIthinkitisanopportunetimeformetotakeastepbackfromcrankingoutlotsofpatternandgivemyselfsomespaceandtimetowrite,reflect,andworkonthepreservation,restoration,andpromotionofthosemoreimportantpatternsthatalreadyhavebeenidentifiedandtoidentifygapsthatneedfilling.Willyoujoinmeinthiseffort?REFERENCES[AHLSWY]Acherkan,E.,Hen-Tov,A.,Lorenz,D.,Schachter,L.,Wirfs-Brock,R.,andYoder,J.“DynamicHookPoints.”ProceedingsofAsianPLoP2011[Arn]Arnheim,R.VisualThinking,UniversityofCaliforniaPress;SecondEdition,Thirty-FifthAnniversaryPrinting,2004[Dem]Demeyer,S.,Ducasse,S.,Nierstrasz,O.Object-orientedReengineeringPatterns,MorganKaufman,2003.[Evan]Evans,E.Domain-DrivenDesign:TacklingComplexityintheHeartofSoftware,Addison-Wesley,2003.[Foot]Foote,B.,Yoder,J.“BigBallofMud”inProceedingsoftheFourthConferenceonPatternsLanguagesofPrograms(PLoP'97/EuroPLoP'97)Monticello,Illinois,1997.AlsoinPatternLanguagesofProgramsDesign4,editedbyNeilHarrison,BrianFoote,andHansRohnert.Addison-Wesley,2000.[Gamma]Gamma,E.,Helm,R.,Johnson,R.,Vlissides,J.DesignPatterns:ElementsofReusableObject-OrientedSoftware.Addison-Wesley,1995.[HNSWY10]Hen-Tov,A.,Nikolaev,L.,Schachter,L.,Wirfs-Brock,R.,andYoder,J.“AdaptiveObject-ModelEvolutionPatterns.”Proceedingsofthe8thLatinAmericaConferenceonPatternLanguagesofPrograms(SugarLoafPLoP2010),2010.[HLNSWY10]Hen-Tov,Lorenz,D.,A.,Nikolaev,L.,Schachter,L.,Wirfs-Brock,R.,andYoder,J.“DynamicModelEvolution.”Proceedingsofthe17thPatternLanguageofProgramingConference(PLoP2010),2010.[Hva2015]Hvatum,L.andWirfs-Brock,R.“PatternstoBuildtheMagicBacklog”.20thEuropeanConferenceonPatternLanguagesofProgramming(EuroPLoP),EuroPLoP2015,2015.[Hva2017]Hvatum,L.andWirfs-Brock,R.“PatternStoriesandSequencesfortheBacklog:ExpandingtheMagicBacklogPatterns”.24thconferenceonPatternLanguagesofProgramming(PLoP).PLoP2017,2017.[Hva2018]Hvatum,L.andWirfs-Brock,R.“ProgramBacklogPatterns:ApplyingtheMagicBacklogPatterns”.23rdEuropeanConferenceonPatternLanguagesofProgramming(EuroPLoP).EuroPLoP2018,2018.[Jack]Jackson,M.ProblemFrames:Analyzingandstructuringsoftwaredevelopmentproblems,Addison-Wesley,2001.[Rhod]Rhodes,B.PythonDesignPatterns.Website.April2020.https://python-patterns.guide.

ShouldWeStopWritingPatterns? 14

[Thom]Thompson,J.Webpage.GangofFourDesignPatterns.April2020.https://springframework.guru/gang-of-four-design-patterns/[Wirf]“AreSoftwarePatternsSimplyaHandyWaytoPackageDesignHeuristics?”[Wirf90]Wirfs-Brock,R.,Wilkerson,B.,Wiener,L.DesigningObject-OrientedSoftware.PrenticeHall,1990.[Wirf02]Wirfs-Brock,R.,McKean,A.Object-OrientedDesign:Roles,Responsibilities,andCollaborations.Addison-Wesley,2002.[Wir2016]Wirfs-Brock,R.andHvatum,L.2016.MorePatternsfortheMagicBacklog.23rdConferenceonPatternLanguagesofProgramming(PLoP2016),2016.[Wirf2019]Wirfs-Brock,R.andHvatum,L.2019.“WhoWillReadMyPatterns?OnDesigningaPatternsBookforTargetedReaders”.26thConferenceonPatternLanguagesofProgramming(PLoP2019),2019.[WTN]Wirfs-Brock,R.,Taylor,P.,Noble,J.“ProblemFramePatterns:AnExplorationofPatternsintheProblemSpace”inProceedingsofthe13thPatternLanguageofProgramsConference(PLoP2006),2006.[WY]Wirfs-Brock,R.,Yoder,J.“PatternsforSustainableArchitectures”inProceedingsofthe19thPatternLanguagesofProgramsConference(PLoP2012),2012.[WYG]Wirfs-Brock,R.,Yoder,J.,Guerra,E.“PatternstoDevelopandEvolveArchitectureDuringanAgileSoftwareProject.”Proceedingsofthe22ndPatternLanguagesofProgramsConference(PLoP2015),2015[WYW07]Welicki,L,Yoder,J.,Wirfs-Brock,R.“RenderingPatternsforAdaptiveObjectModels.”Proceedingsofthe14thPatternLanguageofProgramsConference(PLoP2007),2007.[WYW08]Welicki,L.,Yoder,J.,Wirfs-Brock,R.“TheDynamicFactoryPattern”Proceedingsofthe16thPatternLanguageofProgramsConference(PLoP2008),2008.[WYW09]Welicki,L.,Yoder,J.,Wirfs-Brock,R.“AdaptiveObject-ModelBuilder.”Proceedingsofthe16thPatternLanguageofProgramsConference(PLoP2009),2009.[YWA2014]YoderJ.,Wirfs-BrockR.,andAguilarA.,“QAtoAQ:PatternsabouttransitioningfromQualityAssurancetoAgileQuality,”3rdAsianConferenceonPatternsofProgrammingLanguages(AsianPLoP),2014.[YW2014a]YoderJ.andWirfs-BrockR.,“QAtoAQPartTwo:ShiftingfromQualityAssurancetoAgileQuality,”21stConferenceonPatternsofProgrammingLanguage(PLoP2014),2014.[YWW2014b]YoderJ.,Wirfs-BrockR.andWashizakiH.,“QAtoAQPartThree:ShiftingfromQualityAssurancetoAgileQuality:TearingDowntheWalls,”10thLatinAmericanConferenceonPatternsofProgrammingLanguage(SugarLoafPLoP2014),2014.[YWW2015]YoderJ.,Wirfs-BrockR.andWashizakiH.,“QAtoAQPartFour:ShiftingfromQualityAssurancetoAgileQuality:PrioritizingQualitiesandMakingthemVisible.”22ndConferenceonPatternsofProgrammingLanguage(PLoP2015),2015.

ShouldWeStopWritingPatterns? 15

[YWW2016a]YoderJ.,Wirfs-BrockR.andWashizakiH.,“QAtoAQPartFive:BeingAgileatQuality:GrowingQualityAwarenessandExpertise.”5thAsianConferenceonPatternsofProgrammingLanguage(AsianPLoP2016),2016.[YWW2016b]YoderJ.,Wirfs-BrockR.andWashizakiH.,“QAtoAQPartSix:BeingAgileatQuality:EnablingandInfusingQuality,”24thConferenceonProgrammingPatternsofProgrammingLanguage(PLoP2016),2016.