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