- Kast din egen kode med et smil!

"Jo mer slit og hardt arbeid som er lagt ned, jo vanskeligere er det" skriver Thomas Nøkleby i Capgemini, som har noen gode tips.

📸: Ole Petter Baugerød Stokke
📸: Ole Petter Baugerød Stokke Vis mer

Det kan være vanskelig å kaste sin egen kode, når behovet for det er til stedet, for eksempel ved prototyping eller at prosjektet man er på går nye veier.

Her er litt bakgrunn til hvorfor det er slik, og noen teknikker for å få gjort det lettere.

Craftmanship-eieforhold til koden

Mange utviklere fokuserer ikke kun på å levere noe som, for det meste, fungerer, men også å levere noe som er elegant og bra. For å få til dette, kreves det innsats og fokus — både på forberedelser rundt selve prosessen, alt fra å lese bøker til å gå på konferanser, prøving og feiling, og ikke minst ekstra innsats og en form for perfeksjonisme når man lager, tester og modifiserer koden.

Den ekstra innsatsen man legger ned i utviklingsprosessen gir et eget naturlig eieforhold — “denne koden er lett forståelig, og så robust som jeg klarer å lage den. Den har høy kvalitet, slik jeg liker det, og slik det skal være”.

På samme måte som det smerter å kaste et vellaget møbel som ikke lenger passer inn (men ikke er ødelagt i seg selv), smerter det å kaste denne vellagde koden, med så gode og fine abstraksjoner, og som har kostet så mye innsats å lage.

Identitet og verdi

Når man anser seg selv som en god utvikler og god på å lage kode, kan enhver ting som truer koden — alt fra kritiske kommentarer i en Pull Request, til å faktisk fjerne kode fordi funksjonalitet skal endres — også true ens selvtillit og forståelse av egenverdi.

Det kan også bli ekstra emosjonelt vanskelig i Pull Requester, når en får kommentarer på den faktiske kodestruktur og løsningsvalg. Når identitet knyttes til intelligens (god kode) eller innsats, kan innspill i noen tilfeller oppfattes truende og negativt.

Det kan sammenlignes med hvordan det anbefales å gi barn komplimenter basert på god innsats fremfor intelligens når de får noe til.

Eierforhold til prosjektet

Når man har lagt ned blod, svette og tårer over en lenger tidsperiode, styrt retningen på et system (eller signifikant del-funksjonalitet) og sett at dette gir signifikant verdi og resultater, får man en tilknytning til softwaren.

Det er noe man selv har utviklet og formet, og lært og utprøvd nye utviklingsteknikker og nye abstraksjoner med. Det føles naturlig.

«Når man har lagt ned blod, svette og tårer (...) får man en tilknytning til softwaren»

Etterhvert kan man bli så tilknyttet til arkitekturen på systemet at et ønske om ny og utvidet funksjonalitet som ikke passer inn i sin egen forståelse av hva systemet bør gjøre, blir emosjonelt vanskelig å legge til — og å fjerne funksjonalitet blir enda verre.

Reframing — andre synsvinkler

Det er, i mange tilfeller, mulig å se problemstillingen på en annen måte. Det finnes alltid flere synspunkt og vinkler. Problemet kan imidlertid være å se dem, og ikke minst også å tro på dem. Er glasset halvtomt eller halvfullt?

Jeg opplever det som mer nyttig og konstruktivt å tenke at verdien man tilfører ikke er koden i seg selv, men kunnskapen man bidrar med.

Denne kunnskapen kan være alt fra råd og tips til endelig kode, eller kunnskapen som organisasjonen sitter igjen med etter nye eksperimenter med ny kode og brukere, som viste at funksjonalitet implementert ikke var til nytte. Dette blir stadig viktigere da en av de fem pilarene i digital transformasjon er “fast & cheap experimentation”. Som et resultat er det mye kode som vil bli kastet.

Som konsulent er fokuset på å hjelpe kunden. Noen ganger er den mest verdifulle hjelpen å ta kjappe tanker notert ned på den klisjefylte servietten, og implementere det beste man kan gjette seg til fra dette, så en veldig travel kunde med minimal innsats fra eget fast ansatt personell, kan få bygd funksjonalitet.

Tenke nytte, ikke kode

De alle fleste av oss som utvikler, utvikler noe som er til nytte for andre mennesker, eller støtter opp under software, prosesser eller infrastruktur som allerede finnes. Det er denne nytten som faktisk er viktig, ikke koden i seg selv.

Så om du må kaste eller omforme mye kode for å kunne levere bedre eller mer funksjonalitet, så er det faktisk nyttig. Koden du lager er tross alt kun et verktøy.

Det er mulig å fokusere på sluttbrukerens nytte og glede. Det kan bli svært abstrakt, for eksempel om man utvikler en bedre serverkode for et obskurt system, men med fokus og oppmerksomhet, er det mulig å dra ut tilfredsstillelse av dette også, altså få en følelse av å ha utrettet noe, av å lage noe som er nyttig, dra verden framover.

Husk — kildekode er gjeld

Det er viktig å huske at selv om man intuitivt gjerne ser på kildekode som noe med verdi i seg selv, så er ikke det nødvendigvis riktig. Etterhvert som uttrykket teknisk gjeld kom på banen og ble mer kjent, begynte flere å se at kode i seg selv ikke nødvendigvis er utelukkende positiv, det du lager VIL ha teknisk gjeld, og muligens også designgjeld.

Hver eneste snarvei, hvert eneste halvgode variabel-, metode-, klasse- og pakkenavn er en potensiell snubletråd for neste utvikler (dette inkluderer deg selv om noen altfor få uker).

«Det du lager vil ha teknisk gjeld, og muligens også designgjeld.»

Et enkelt tankeeksperiment illustrerer dette: Om du skal gå gjennom en kode som implementerer en integrasjon, gitt ellers samme kodekvalitet, lesbarhet og funksjonalitet, hva ville du heller satt deg inn i; den som er 10 000 kodelinjer eller den som er 2000?

Som nevnt her er det faktisk lettere å skrive kode enn å lese og forstå kode. Jeg tror det er flere grunner til dette. Koden du skriver baserer seg på abstraksjoner og tolkninger. Mange, men ikke alle disse abstraksjonene vil være eksplisitt definert i koden. Tolkningene dine vil likevel neppe være det (selv om du mot all sannsynlighet skulle ha svart belte i kommentarer).

Disse implisitte abstraksjonene, og alle tolkningene dine vil ikke være tilgjengelig for den neste utviklere som leser koden din. Dette resulterer i at selv om koden din tok tid å komponere, renskrive og teste, kan det faktisk være at den beste måten for en ny utvikler å sette seg inn i applikasjonsdomenet er å skrive ny kode (og da selv måtte utarbeide de abstraksjoner og tolkninger som er implisitt i koden, og slik opparbeide seg den nødvendige kompetansen på dette domenet. Slik blir koden din ikke et uforanderlig, uerstattelig byggverk, men din personlige tolkning og løsning på sluttbrukers problemer og verdier. Den er ikke Notre Dame, men et kjedelig grått forretningsbygg.

Stoisisme

Stoikerne, en bevegelse som oppstod ca. 200 f.Kr, hadde som mål å oppnå en indre ro. For å jobbe mot dette fokuserte de på å skille fornuft og følelser, som prinsipp, og hadde en rekke praktiske mentale verktøy for å oppnå dette. Mange av disse er nyttig i dag:

  • Fokusere på å aktivt gi slipp, og ikke bekymre seg for det man ikke kan påvirke (din bekymring påvirker jo ikke situasjonen på noen som helst måte, og tapper deg bare for energi). Om utviklingen i et prosjekt skifter spor (eller kunden skifter retning) og biter av det du har laget ikke lenger er nyttig, så er det ikke noe du kan gjøre med det. Gi slipp og jobb med det du kan endre.
  • Negativ visualisering: ting kan alltid være verre (et unntak her om du da er på en Boeing 737 MAX med en ødelagt sensor). Slik visualisering er å tenke og se for seg alt som kunne ha gått galt, og alt som kunne ha vært verre. Ved slik negativ visualisering så kan man erfare at man setter mer pris på situasjonen slik den er (man har lønnet arbeid, man er generelt mett og varm, man har gode venner, Norge er et generelt trygt land). Mennesker generelt er svært gode til å tilpasse seg, og vil dessverre også tilpasse seg en høy levestandard, og et trygt miljø. Slik visualisering kan hjelpe med å nullstille dette. Mer spesifikt: dette kan hjelp til med å dempe den emosjonelle responsen på at du må kaste deler av koden (det kunne jo hendt at all koden du hadde laget ble kastet, og at den ble skrevet ut, rituelt brent og ledd av).
«Jo mer slit og hardt arbeid som er lagt ned, jo vanskeligere er det.»

Ja, det er vanskelig

Det er vanskelig. Jo mer slit og hardt arbeid som er lagt ned, jo vanskeligere er det.

Men, selv om man har brukt ukesvis på å få opp en integrasjon mot, så blir løsningen bedre om man kaster hele integrasjonen og går mot et mye enklere og bedre system. Jo oftere man gjør dette, jo lettere blir det.

Ikke ta det personlig — det blir lettere. Lykke til!