Should we stop writing design patterns.v4
15
Should We Stop Writing Patterns? 1 Should we stop writing design patterns? Rebecca Wirfs-Brock, Wirfs-Brock Associates This essay reflects on experiences I’ve had and what I’ve learned over the past 15 years of writing software design patterns. I’ve come to believe that if we want to broadly increase pattern literacy, relevancy, and long-term impact, some things need to change. Most importantly, I believe that change needs to start with pattern writers, like me. Instead of indiscriminately writing even more patterns I should focus more on connecting, relating, promoting, and refreshing existing impactful patterns. Changes also need to be made in how our community of long-time pattern authors and advocates present, organize, and promote patterns to the rest of the world. Design Patterns, Process Patterns, and Learning from Writing Patterns I’ve written dozens of patterns with several colleagues and friends. The topics range from software requirements to software design and architecture to software development process and practice patterns. Some of our patterns have been technical, detailed patterns for a specific architecture style (specifically, Adaptive Object Models) [AHLSWY, WWY07, WYW08, WYW09, HNSWY10, HLNSWY10]. Others have been about architecture practices on Agile projects [WY, WYG]. Still others have been about patterns for improving software quality [YWA2014, YWW2014a, YWW2014b, YWW2015, YWW2016a, YWW2016b]. I’ve even ventured to write patterns about managing and evolving meaningful product backlogs for complex, long-lived engineering products [Hva2015, Wirf2016, Hva2017, Hva2018, Wirf2019]. The discipline of writing patterns has been mostly fun and only occasionally challenging. Surprisingly, one of the most difficult aspects of writing patterns has been getting sufficiently rich and useful critiques from pattern writing workshops. Sometimes my fellow writing workshop colleagues have been helpful, at other times they’ve barely grasped my patterns. This is mostly because PLoP conferences have become venues for reviewing many more kinds of patterns than those for designing, building, and managing software development products and projects. Not many experienced designers and architects attend pattern writing conferences these days. So these days, most of my exposure to new design ideas and inspiration comes from outside the patterns community. Through my pattern writing, I’ve immersed myself in pattern trivia and become a student of patterns and Christopher Alexander’s writings and philosophy. And yet, I still feel like an patterns community outsider. Inside the patterns community I may
Transcript of Should we stop writing design patterns.v4
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.
