Post on 10-Jul-2020
The Magazine for Agile Developers and Agile Testers
© Tyler Olson - Fotolia.com
October 2010
issue 4www.agilerecord.com freedigitalversion madeinGermany
49www.agilerecord.com
The software business resides in a constant crisis. This crisishasalreadylastedsincethesixties,andeverydecadesincethenseemstohavehadananswertoit.AmongthemostpopularandmostrecentmovementsweretheSoftwareEngineeringandtheAgilemovement.InhisbookSoftware Craftsmanship - The New Imperative[1]PeteMcBreenarguesagainsttheengineeringme-taphorandexplainswhyitjustholdsforverylargeorverysmallprojects,butnotforthemajority,themediumsizedsoftwarede-velopmentprojects.
AsAlbertEinsteinsaid,“We cannot solve our problems with the same thinking we used when we created them”. So far, everyaspectofthesoftwarecrisisturnedouttobeselfinflictedinor-der tosell trainingoreducationalcourseson thesolution thathappened to bemainstreamat the time. Sinceessentially, all models are wrong, but some are useful(GeorgeBox),thisarticlewilltakeacloserlookattheusefulaspectsofthelatestanswerstothesoftwarecrisis,softwareengineeringandcraftsmanship.
Toavoidanyconfusion,thetermsoftwaredevelopmentinthisar-ticlewillmeanprogramming,testing,documentinganddelivery.Similarly,asoftwaredevelopermaybeaprogrammeraswellasatester,atechnicalwriterorareleasemanager.Iwillprovideacompellingviewontheoveralldevelopmentprocessandcompa-reittothetermswemayhaveadaptedfromsimilarmodelslikeSoftwareEngineeringorSoftwareCraftsmanship.
From Software Engineering...Engineeringconsistsofmanytradeoffs.Forexample,anengi-neerdevelopingacarmakesseveraltradeoffs:
• fuelconsumptionvs.horsepower
• horsepowervs.finalprice
• enginesizevs.carweight.
Anengineerconsidersthesevariableswhenconstructingacarandusesatradeoffdecisiontoachieveacertaingoalthatthe
carmanufacturerwouldliketoreach.Therebyhewillensurethatthecarissafeenoughgiventhetimehehastodevelopthecar.
Softwareprogrammersaswellassoftwaretestersalsodealwithtradeoffsintheirdailywork.Forexample,asoftwaretestercon-sidersthecostofautomationandthevalueofexploration.Themoretimethetesterspendsonautomatingtests,thelesstimethereisforexploringtheproduct.Themoretimeisspentonex-ploration,thelesstimewillbeavailabletoautomateregressiontestsforlaterreuse.Figure1illustratesthistradeoff.
Thelevelofautomatedtestingconstitutesanothertradeoffdeci-sion.Automatingatestatahighsystemlevelcomeswiththeriskof reducedstabilitydue tomanydependencies in thesurroun-dingcode.Automating thesame testata lowerunit levelmaynotcoverintermoduleintegrationproblemsorviolatedcontractsbetweentwomodules.Figure2showsthistradeoff.
© M
arzanna Syncerz - Fotolia.com
Developing Software Developmentby Markus Gärtner
Figure 1: The exploration vs. automation trade off in software testing
50 www.agilerecord.com
Similarly, therearefoursuchtradeoffsmentionedintheAgileManifesto.Thelastsentencemakesthemexplicit:
“Thatis,whilethereisvalueintheitemsontheright,wevaluetheitemsontheleftmore.”
Usingthesamegraphicalrepresentationasbefore,figures3(a)3(d)illustratethevaluesfromtheAgileManifesto:
At timesa softwareproject calls formoredocumentation. Theprojectmembersbythenarebetteroffspendingmoretimeondocumentationandlesstimeoncreatingthesoftware,therebycreatinglesssoftware.Similarly,foranoncollaborativecustomermoretimemaybespentonnegotiatingthecontract.Thetradeoffsbetweenindividualsandinteractionsasopposedtoprocess-esandtoolsaswellasrespondingtochangeopposedtofollow-ingaplanneed tobedecided foreachsoftwareproject.Agilemethodspreferthelight-weightdecisionstothesetradeoffs,butkeepthemselvesopenforheavyweightapproacheswhenprojectandcontextcallforit.
... towards craftsmanship ...In his book[1], Pete McBreen describes the facets of crafts-manship by and large.Wehave to keep inmind, though, thatcraftsmanship just likeengineeringprovidesanothermodelonhowsoftwaredevelopmentcanwork.Thismodelissuitableforunderstandingthebasicprinciples,but,aswitheverymodel, it
leavesoutessentialdetailsresultinginasimplifiedviewontheoverallsystem.
McBreen’smainpointisthatthesoftwareengineeringmetaphordoesnotprovideawaytointroducepeoplenewtosoftwarede-velopmenttotheirwork.Thereforeheintroducesthecraftmeta-phor.TheSoftwareEngineeringmodeldoesnotprovideanan-sweronhowtoteachnewjuniorprogrammers,testers,technicalwriters,anddeliverymanagersontheirjob.Andinfact,Prof.Dr.EdsgerW.Dijkstraalreadynoticedthisin1988.Backthen,Dijk-strawroteanarticleonthecrueltyofreally teachingcomputerscience[2].AccordingtoDijkstra,theengineeringmetaphorforsoftware development and delivery leaves toomuch room formisconceptions,sincethemodellacksessentialdetails.
Thecraftanalogyprovidesamodelforteachingpeoplenewtosoftwaredevelopment on the job, anddoes so in a collabora-tivemannerbychoosingpracticestofollow,deliberatelearningopportunitiesandprovidingtheproperslacktolearnnewtech-niquesandpractices.Alltheseaspectsarecrucialtokeepthede-velopmentprocessvital.Experiencedpeopleteachtheiryoungercolleagues. The younger colleagues learn how to do softwaredevelopmentwhileworkingonaproject.By taking the lessonslearneddirectlyintopractice,newandinexperiencedworkersgetto know how to develop software in a particular context. Overtime,thisapproachcreatesasolidbasisforfurtherdevelopmentinsoftwareandaswellaspersonal.
... and beyondThereareotheraspects in thecraftmetaphor,although theseideas,too,hadbeenflowingaroundsincetheearlierdaysoftheSoftwareEngineeringmovement.Takingprideinyourdailywork,caring for the needs of the customer, and providing the bestproductwithinthegiventime,moneyandqualityconsiderationsthatthecustomermade.Ofcourse,everysoftwaredevelopmentteammemberisaskedtoprovidetheirfeedbackonthefeasibili-tyoftheproducttobecreated.Thisincludesprovidingapersonalviewonthetradeoffsthateachindividualmakestoestimatethetargetedcostsanddates.
Software DevelopmentDijkstrawrote in late1988about the cruelty of analogies [2].Likewise,a fewyearsearlierFrederickP.Brooksdiscussedtheessenceandtheaccidentsofpastsoftwareproblems[3].Brooksstatedthathedidnotexpectanymajorbreakthroughinthesoft-wareworldduring thetenyearsbetween1986and1996thatwouldimprovesoftwaredevelopmentbyanyorderofmagnitude.Reflectingbackonthe1990s,hispointseemstoholdtoacer-taindegree.
Since these twopioneers in thefieldof softwaredevelopmentwrotedowntheprospectsoffutureevolutions,anotherdecadehaspast.Reflectingonthepointstheymadeaboutaquarterofacenturyago,mostofthemstillhold.However,thepasttenyearsofsoftwaredevelopmentwithAgilemethods,testdrivendevel-opmentandexploratorytestingapproachesshowsomebenefitsinpractice.Whatweasasoftwareproducing industryneed tokeepinmind,however,isthefactthatsoftwareengineeringas
Figure 3: The four Agile value statements as trade offs
Figure 2: The composition decomposition trade off in software testing
51www.agilerecord.com
wellassoftwarecraftsmanshipareanalogies,ormerelymodels.Theyprovideheuristics,andheuristicsarefallible.Ontheotherhand,thesemodelsprovideuseful insightsthathelpusunder-standsomefractionsofourwork.Themodelsfocusonacertainaspectofthedevelopmentprocess,whileleavingoutdetailsthatmaybeessentialattimesbutnotforthecurrentmodelinuse.
Fromtheengineeringmetaphor,tradeoffsareuseful.Giventhecomplexity ofmost softwareprojects, tradeoffsprovideawaytokeep theprojectundercontrol,whilestilldeliveringworkingsoftware.Systemsthinkingcanhelptoseethedynamicsatplaytomakedecisionsbasedontradeoffs.Fromthecraftanalogy,apprenticeshipshelptoteachpeopleonthejobandhelpthemmastertheirskills.Wheretraditionaleducationsystemsfail,theappealingofdirectcooperationwithanapprenticehelpstoteachpeoplerelevantfacetsoftheirdaytodaywork.
Whiletheanalogieshelp,weneedtokeepinmindwhatAlistairCockburnfoundoutinhisstudiesonsoftwareprojects[4]:
• Almostanymethodologycanbemadetoworkonsomeproj-ects.
• Anymethodologycanmanagetofailonsomeprojects.
Thatsaid,theanalogiesapplyattimes.Weneedtolearnwhenamodeloranalogyappliesinordertosolveaspecificproblem,andwhentouseanothermodel.Nosingleanalogyholdsallthetime,sofinallycreatingandmaintainingasetofanalogiesisessentialforthepeopleinsoftwaredevelopmentprojects,inordertocom-municateandcollaborate.■
References[1] Software Craftsmanship The New Imperative, Pete Mc-
Breen,AddisonWesley,2001
[2] On the cruelty of really teaching computing science, Prof.Dr.EdsgerW.Dijkstra,UniversityofTexas,December1988
[3] No Silver Bullet Essence and Accidents of Software Engi-neering,FrederickP.Brooks,Jr.,ComputerMagazine,April1987
[4] Characterizingpeopleasnonlinear,firstordercomponentsin software development, Alistair Cockburn, Humans andTechnology,1999
Markus Gärtner is a senior software de-veloper for it-agile GmbH in Hamburg, Germany. Personally committed to Agile methods, he believes in continuous improve-ment in software testing and programming through skills. Markus co-founded the European chapter on
Weekend Testing in 2010. He blogs at blog.shino.de and is a black-belt in the Miagi-Do school of software testing.
> About the author