Vakker kode fungerer bedre

Jeg er en sånn programmerer som bruker mye magefølelse og intuisjon. Kode skal se bra ut, den skal føles riktig.

For noen dager siden hadde Computerworld en artikkel hvor de skrev om Vakker programvarekode. De fortalte at det er svært vanlig å vurdere hvor vakker kode er, og at de mest erfarne utviklerne er de mest estetikk-orienterte. Artikkelen snakket om studier som viser at vi vurderer estetiske kvaliteter i kode før vi vurderer korrekthet, og at mye tyder på at identifikasjon av stygg kode brukes som indikator på problematisk kode.

Men artikkelen skraper bare i overflaten av hvorfor estetikk er viktig – hvorfor eksperter dømmer kode ut i fra hvor vakker den er. For skal ikke kode bare gjøre jobben sin.., spiller det noen rolle hvordan den ser ut? Datamaskinen bryr seg jo ikke. I går kom jeg til eksempel over en blogpost som hardnakket hevder:

“Your job is to solve a business problem, not to create a thing of beauty. Your ideals—what you feel is attractive, innovative, or effective—are secondary to what your client needs.”

Det er flere grunner til at vakker kode er viktig. Men det jeg synes er mest interessant er hva “vakkert” er for noe. Siden vi mennesker gjennom evolusjonen har utviklet denne egenskapen – å synes at noe er fint – så må det jo nesten ha en funksjon.

Og dette vet vi faktisk en god del om. Når du synes noe er vakkert så kan du se på det som at intuisjonen din forsøker å fortelle deg at det du ser er bra. Noe som er “riktig”, noe som vil fungere godt. Studier har gang på gang vist at vakre utgaver av fremkomstmidler, redskaper o.l. er bedre enn de mindre vakre utgavene (se linker nederst). Tiltalende websider er enklere å bruke enn stygge websider. Dette er ikke fordi vakkerhet gjør ting bedre, men fordi vi synes at velfungerende ting er vakre!

Hjernen vår har to moduser som fungerer side ved side. L-modusen (det vi tradisjonelt har kalt venstre hjernehalvdel) er sekvensiell og analytisk. Det er den vi resonerer med, det er den som er vår indre monolog. R-modusen derimot (trad: høyre) kan du se på som en prossess av veldig mange parallelle tråder. Den er utrolig flink til å søke i hukommelsen vår og finne mønstre blant alle våre erfaringer, og gjennom det løse problemer.

Men R-modusen har ikke noe språk – den bruker ikke ord – og for at vi skal bli bevisste på hva R-modusen kommer opp med må det kommuniseres gjennom andre kanaler. Bilder. Følelser. Intuisjon. Estetikk!

Dyktige utviklere (og dyktige utøvere innen de fleste andre felt) lærer seg å bruke R-modusen som en viktig ressurs for å løse problemer. Gjennom erfaring har de opparbeidet seg det man kaller en intuitiv forståelse. I foredraget Hammock-driven Development forklarte Rich Hickey i 2010 hvordan han laster opp hjernen sin med så mye informasjon som mulig om et problem, for så å slappe av (i hengekøyen) og bevisst la være å tenke på problemet. Å “la være å tenke” vil si å roe ned L-modusen, slik at R-modusen får jobbe i fred. Da kommer løsningene raskere, helt “av seg selv”.

Andre kjente teknikker for å aktivere R-modusen er å gå seg en tur, spille foosball på pauserommet, eller på andre måter aktivere kroppen og distrahere den indre monologen. Å sitte stille forran PC-skjermen er ikke den beste måten å løse komplekse problemer på.

Så skjønnhet er viktig! Når du synes kode er vakker er det kanskje hjernen din som bruker en snarvei til å fortelle deg at den er bra.

Men du skal vær bare klar over at R-modusen ikke er feilfri. Vi har alle våre bugs, og intuisjonen vår tar ofte feil. Kjente forelesere i software craftsmanship-bevegelsen som for eksempel Dan North snakker om såkalte cognitive biases (vurderings-skjevhet). R-modus kan brukes til å komme opp med løsningsforslag eller forslag til sannheter, men så bør man analysere (bruke L-modus, bevisst logikk) for å verifisere. I Pragmatic Thinking & Learning (som jeg på det sterkeste vil anbefale) sier Andy Hunt:

“Lead with R-mode; follow with L-mode.”

I den moderne, vitenskapsbaserte verden – og kanskje spesielt i Vesten – er vi veldig fokusert på L-modusen. Det er den vi aktiviserer på skolen, og vi lærer svært lite om hvordan vi kan utvikle intuisjonen vår. Men skal man bli virkelig dyktig er det ingen vei utenom om tappe potensialet som ligger “i høyresiden”.

Vakker kode er ikke bedre i seg selv. Men utviklere synes at kode som kommuniserer godt, er fleksibel og har lav kompleksitet, er vakrere enn annen kode. Og dette kan man bruke som en snarvei; men kan skrive kode man synes er fin, mens det som egentlig skjer er at underbevisstheten hjelper deg og passer på at du gjør ting så godt som mulig, basert på dine tidligere erfaringer.

Så forsøk å gjøre koden din vakker – for det er en grunn til at du har en estetisk sans.

Vakker kode er som regel bedre!

Referanser:
* Emotional Design: Why We Love (or Hate) Everyday Things
* Apparent Usability vs. Inherent Usability
* Aesthetics and Apparent Usability
* A Neuropsychological Theory of Positive Affect and Its Influence on Cognition
* Automatic Effects of Brand Exposure on Motivated Behavior: How Apple Makes You “Think Different”

Kategorier: OO-design/clean code, Softwareutvikling.
RSS feed for kommentarene. Tilbaketråkk.