Metaforer är ofta dåliga och lätta att slå hål på snarare än att de hjälper. Ändå envisas vi med att år efter år använda husbyggarmetaforer till exempel för att beskriva programutveckling, trots att det leder oss i mångt och mycket i fel riktning.

Ett annat exempel är när extrem programmering var nytt för några år sedan. Jag var lite fundersam till hur man skulle resonera kring ”you ain’t gonna need it” yagni. Jag beskrev en teoretisk situation för Martin Fowler och frågade honom hur jag borde resonera. Exemplet jag tog var att jag har en liten båt och jag bor i Sverige. Om jag inte förbereder båten på våren och sjösätter den så innebär det att när det är en solig dag och jag vill ut på sjön så har jag ungefär en dags arbete att förbereda båten. Nästa dag är det troligen inte fint väder längre. Hur bör man tänka på yagni här? Fowler svarade: ”I don’t like metaphors!”

Det var inte riktigt det svar jag hade förväntat mig, men med lite distans till det hela så håller jag med.

Ett annat problem som vi blir påminda om då och då är att metaforer åldras. En vanlig symbol för att spara är fortfarande disketten, men för tonåringar så är det bara en bild vilken som helst utan att de egentligen blir hjälpta av den.

Trots att de flesta metaforer kan tas sönder finns det trots allt potentiellt mycket kraft i bra metaforer. En väl använd metafor i ett visst sammanhang och med ett visst syfte kan hjälpa beskrivningen. Hjälper den, ja då är den bra.

Av någon anledning verkar det som att metaforer ofta fungerar bättre ”åt andra hållet”, det vill säga att i stället för att försöka beskriva programutveckling med metaforer från den vanliga världen så kan det för oss fungera bra att göra tvärtom.

Ett exempel som gjorde det tydligt för mig var för några år sedan då jag hörde festfixare Micael Bindefeld få frågan om vad som är viktigast att tänka på för en lyckad fest. Han svarade: ”Rätt människor!” Ah, precis som utvecklingsprojekt, även där är ju den enskilt viktigaste framgångsfaktorn att ha rätt människor. Alltså, genom att förstå programutveckling så kan vi också förstå den vanliga världen. Nästa gång vi har bjudning kommer det avslutas med demo där alla får visa vad de åstadkommit under kvällen, sedan blir det retrospektiv!

Jag klankade på att programutveckling inte är som att bygga hus, men vilken metafor skulle då kunna hjälpa oss i stället för att stjälpa? Min favorit för att beskriva programutveckling är... trädgårdsmästaren.

Den gode konsulten kanske säger att om det inte finns någon ny feature som behövs just då, då jobbar hen med någon annan kund. Tvärtom. Städa, fixa, rensa, håll i schack om det är en kodbas som är och ska vara vid liv. Precis vad en bra trädgårdsmästare ägnar mycket av sin tid åt fortlöpande.

Visst är det en kraftfull metafor. Många kodbaser hade mått mycket bättre och kunnat leverera mycket mer affärsvärde om trädgårdsmästaren hade varit rådande!