Värdet av ett estetiskt sinne vid design av program

Att utforma någonting, fysiskt eller abstrakt, är ett utmanande, kreativt och spännande arbete. Det är där, i designlandet, mellan ett identifierat behov och en elegant lösning, som jag vill spendera min tid.

Notera ordet “elegant” i meningen ovan. När man talar om design återfinns nämligen ofta ord som “elegans”, “skönhet”, “estetik”. Jag har en hypotes kring detta: För att kunna göra en bra design, inom ditt valda område, krävs att du har uppnått en kompetensnivå hög nog för att kunna avgöra vad som är vackert eller oskönt. Eller kortare:

God design kräver estetisk känsla.

Det här kanske inte låter speciellt märkligt om du tänker på konst eller hantverk. Men talar vi om utveckling av system och produkter så blir det plötsligt ett ovanligt påstående. Skulle programmerare, nördar, ingenjörer, behöva ha en känsla för vad som är vackert? Löjligt! Läs vidare så ska jag försöka förklara vad jag menar.

Designarbete är utmanande för dess utövare därför att en god design inte kommer av sig själv. Tvärtom. Eric Evans (författare till boken “Domain-Driven Design”) brukar säga att den första lagen inom modellering (design av en abstraktion) är:

“Den första modellen kommer att vara fel.”

Med det menar Eric att det första förslaget vi kommer att tänka på oftast inte är det bästa (mest lämpliga). För problem där design är användbart finns det ofta många godtagbara lösningar. Vissa lösningar är snyggare än andra, men den allra första kommer inte att vara en av dem.

Det här kanske låter oroväckande för en icke-designer, men det är faktiskt inget vi designarbetare ligger vakna för om nätterna. Vi har verktyg att för att lösa problemet ändå. Ett sådant verktyg, det finns flera, innebär att iterera fram designen, det vill säga att ständigt återkomma till designen. Det betyder att vi frekvent omprovar designen, prövar den i fler situationer, på fler människor, anpassar den till nya krav som framkommit och förfinar den med vår eftertankes klokhet. Man kan säga att vi arbetar med kontinuerlig eller evolutionär design.

Låt mig ta mitt eget område, systemutveckling, som exempel. Inom programmering kallas det främsta verktyget för kontinuerlig design refaktorisering. Refaktorisering är en samling tekniker som i korthet innebär att förbättra den inre designen av ett system utan att förändra dess yttre beteende. Tekniken blev känd hos den stora massan av programmerare i början av 2000-talet när utvecklingsmetoden Extreme Programming (XP) snabbt blev populär.

Ok, så alla systemutvecklare knådar ständigt sin design med tekniker från refaktorisering, vad fint! Tyvärr inte. Allt står inte rätt till i utvecklarland. Problemet med refaktorisering är att det kräver så oerhört mycket disciplin. Det är känt sedan länge. Martin Fowler, som har skrivit bibeln inom refaktorisering, skriver:

“… XP, which requires a lot of discipline to execute.” [2]

Arbetssätt som kräver mycket disciplin har svårare att fastna och kräver ständig påminnelse för att fortsätta med. Vi människor är generellt inte speciellt bra på sådana uppgifter. Om det är för svårt eller för tråkigt gör vi det helt enkelt inte speciellt bra – eller hoppar över det helt. En forskare som har studerat tusentals utvecklingsteam, Alistair Cockburn, säger så här:

“… high-discipline methodologies are fragile … people are unlikely to keep performing those practices over time” [3]

Alistair fortsätter:

“I still find that most people on the team do not refactor often, generally leaving that to the senior project person” [4].

För att förstå disciplinen som krävs vid refaktorisering, tänk dig följande: Du lägger ett pussel i 3D genom att lägga placera in mikroskopiska bitar. Före varje ny bit måste du komma ihåg att se över pusslet där du tänkte lägga biten för att se om du kan förbereda för den nya biten. Efter att du har lagt biten måste du minnas att återigen se över pusslet där du är. När du har lagt ett visst antal bitar bör du se över en större del av pusslet för att se om det fortfarande hänger ihop. Regelbundet måste du se över hela pusslet och bygga om stora delar av det. Det finns inga enkla regler för när pusslet inte passar ihop, det är mest en känsla. Det finns heller inga regler för hur du ska ändra pusslet för att det ska passa ihop, det gör du på känsla. Tänk dig nu att du har kunder som högljutt undrar när pusslet ska levereras, du jobbar på tre pussel parallellt och chefen gormar att vi behöver fler bitar.

Funky Bookshelf

Funky Bookshelf: Quodes Pattern 2006

För att sammanfatta: Inom systemutveckling, och jag misstänker att även andra designyrken egentligen lider av samma problem, behöver vi ständigt och envist förbättra vår design, vilket i sin tur kräver så mycket disciplin att de flesta inte orkar med det. Sannerligen ett dilemma!

Hur kan vi vända den här trenden och vinna matchen? En ledtråd kan vi få genom att studera de som faktiskt håller på med refaktorisering. Hur orkar de? Vad är det som driver dem? Har de hittat någon magisk disciplindryck? Eller är det GI-mat, ginseng och ett slitet Sats-kort som är hemligheten? Från de samtal jag har haft med likasinnade har jag destillerat fram en egenskap som förefaller viktig: Ett estetiskt sinne (jag lovade ju att jag skulle komma tillbaka till det). I fallet programmering är vårt arbetsmaterial programkod. Bra systemutvecklare utvecklar alltså ett estetiskt sinne för kod.

Min teori om hur det här fungerar: Med ett estetiskt sinne för ditt material skär det i hjärtat i en hantverkare/formgivare när du ser något fult eller kanske till och med avskyvärt. Det kan göra dig nästan fysiskt illamående. Du måste rätta detta onda. Den känslan är starkare än motviljan att ta fram verktygslådan igen. Alltså, du går in, gör din magi och världen blir åter en vacker och härlig plats. Och allt var gott.

Har du orkat ända hit, kära läsare, hoppas jag att du har förstått varför ett estetiskt sinne är livsviktigt för alla inom designyrken, inklusive för programmerare. Utan ett estetiskt sinne för mjukvara fungerar inte refaktorisering som det ska på lång sikt. Utan det finns det inget som attraherar utvecklaren till att ständigt fundera på och förbättra desigen för att göra den enkel och tålig mot de framtida, oundvikliga förändringarna. Utan det blir systemen obegripliga, omöjliga att testa, omöjliga att ändra. Att lära sig att känna igen och skapa vacker, ren design framstår plötsligt för mig som något mycket viktigare än någon slags teknikonani.

Referenser:
[1] “Scaling Lean and Agile Development” (s. 126) C. Larman & B. Vodde
[2] “The New Methodology” M. Fowler http://www.martinfowler.com/articles/newMethodology.html
[3] “Agile Software Development” 1 utg. (s. 53) A. Cockburn
[4] ibid (s. 54)

7 thoughts on “Värdet av ett estetiskt sinne vid design av program

  1. Underbart! Jag håller fullständigt med!

    Frågan är bara hur vi som mår illa av fulkod får alla andra att känna samma sak. Hur gör vi med de som inte har detta sinne för estetik?

    • Tack Pierre!

      Det är en väldigt bra fråga som du ställer, för det är helt avgörande. Fler och fler måste komma med på tåget. De som har ett utvecklat sinne för skönhet inom kod kan inte agera “städgummor” åt de som inte har det. Det orkar de inte.

      Det positiva är dock att vi verkligen kan bli bättre. Det finns några som har den här känslan inbyggd, men många andra (nästan alla) tror jag kan lära sig det.

      Tänkte ägna något kommande inlägg åt några tankar om hur vi kan få alla att bli bättre.

      • Tack Jocke för ett väldigt bra inlägg!
        Jag tror inte att det är känslan som saknas, snarare är problemet att många utvecklare inte resonerar om kod i estetiska termer. En spridd uppfattning är att bara koden verka fungera så är den färdig och så rusar man vidare för att implementera nästa funktion. Det som behövs är en förändrad attityd. Utvecklare måste börja resonera om kod. Ett bra sätt att få till en ändrad attytiyd är att praktisera parprogrammering (som jag vet att Jocke är en stark anhängare av). Då tvingar man fram en kontinuerlig diskussion om koden.

      • Hej Petter! Tack för kommentaren! Jag håller med. Det jag skulle vilja lägga till är en förklaring: Jag menar alltså att om man gör så som du föreslår; tränar, resonerar, reflekterar så blir man duktigare. Om du gör det i, säg, 10 år behöver du inte prata så mycket. Du _känner_ direkt vad som känns fel. Det är det jag menar med att du har utvecklat en _känsla_ för designen.

Comments are closed.