Dette er en av flere mantraer jeg lever etter som utvikler, og gjelder for mange områder: kode, dokumentasjon, design, arkitektur, prosesshåndtering. Flere vet mest sannsynlig om denne teorien, men jeg syns uansett det er kjekt å få en påminnelse om den og tenke gjennom eksempler på hvordan dette gjelder prosjekter jeg har jobbet med, eller jobber i, og hva konsekvensene av den er.

Teorien stammer egentlig fra en artikkel om kriminologi, hvor man så på konsekvensene av å la en bygning med knuste vinduer stå ødelagt, og hva som skjedde med denne bygningen. Resultatet kan oppsummeres slik:

Synlige tegn på kriminalitet, antisosial oppførsel og sivil uorden skaper et urbant miljø som oppmuntrer til ytterligere kriminalitet og uorden, inkludert alvorlige forbrytelser. Teorien antyder at politimetoder som tar for seg mindre kriminalitet som hærverk, offentlig drikking og sniking på transportmidler, bidrar til å skape en atmosfære av orden og lovlighet, og dermed forebygger mer alvorlige forbrytelser.

Med andre ord, små mengder kriminalitet skaper mer kriminalitet, og til slutt vil bygningen kollapse på grunn av alt hærverket som er gjort fordi man ikke ser alvoret i at små ting som går uhåndtert, bygger seg opp veldig fort.

Hvordan er dette overførbart til jobben vi gjør?

Hvis man sammenligner kodebasene, dokumentasjonen eller prosessene i teamet sitt med bygningen nevnt over, kan det være veldig gjenkjennelig. For flere er kanskje en variant av stegene under svært kjent:

1. Man starter med Det Fantastiske Systemet hvor all koden er super solid og ingenting kan stoppe den.
2. På grunn av press for å levere en viktig leveranse må man gjøre raske endringer i Det Fantastiske Systemet, noe som fører til noen mindre feil og kode som ikke lenger følger standarder.
3. Enten blir ikke feilene oppdaget i review, eller så aksepterer man dem fordi man skal rette dem opp på et tidspunkt når man har bedre tid, også kjent som teknisk gjeld.
4. Flere raske endringer må gjøres i Det Fantastiske Systemet, som nå ikke lenger er så fantastisk på grunn av dårlig kode fra andre systemer, hvor man har løst problemer på en nesten lignende måte tidligere.
5. Det som en gang var et fantastisk system har nå kommet til et stadie hvor det er skjørt, og endringer tar lang tid og har en høy kostnad, både fordi koden er vanskelig å lese, det mangler tester, og testene som fantes har blitt kommentert ut fordi man ikke hadde tid til å fikse dem for å rette bugen, og av flere andre grunner.
6. Det Fantastiske Systemet begynner å feile horribelt, og man bestemmer seg for å skrive det på nytt i et nytt og bedre format og kaller systemet Det Fantastiske System v2.
7. Gå tilbake til steg 2.

Om ingen tar tak i feilene som fortløpende kommer, råtner koden veldig fort! Dette skaper kode som ingen ønsker å ta i fordi den enten er umulig å teste, eller at det tar for lang tid å nøste opp i hva som foregår, og dermed gjøre endringer.

Det som kanskje er det største problemet med at man knuser et vindu i koden, er hvis dette knuste vinduet blir duplisert fordi det fremdeles tilsynelatende fungerer for uvitende eller uerfarne utviklere. Koden blir da som et virus som sprer seg utrolig raskt. Av erfaring er dette svært treffende når man jobber i team hvor leveringspress er forskjellig fordi utviklerne kommer fra forskjellige land. Ofte kan da det viktigste være å løse problemet der og da for å merkere at problemet er løst uten egentlig å tenke på hva man har gjort. Så lenge koden spytter ut X, og det var det man ble bedt om, så har det ingenting å si hvordan det skjedde.

Det man bør identifisere med slike prosesser, er at teknisk gjeld MÅ fikses! Med andre ord så er det bare å sette av tid og legge den tekniske gjelden som en oppgave som blir prioritert. Om det ikke aksepteres av høyere makter, kan man alltid referere til bildet nedenfor og spørre om de aksepterer kostnaden ved å ikke fikse problemet med en gang.

Hva er løsningen?

• FØLG standarden som er satt i teamet ditt.
• Bruk generelle best practices innenfor området du jobber i.
• Bruk LTS-versjoner og ikke oppgrader så fort det kommer en ny versjon.
• Prøv å bruke et lite sett med teknologier så langt det lar seg gjøre.
• Bruk verktøy på tvers av repoer som tvinger koden til å følge samme standard, som editorconfigs, SonarCloud osv.
• Bruk “The Boy Scout Rule” fra Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Prentice Hall.
• Dedikere faktisk tid til teknisk gjeld per sprint/arbeidsperiode.
• Grundige code reviews. Folk skal dele ansvar for kode som blir pushet.

Listen er ikke fullstendig og en sølvkule for alt, men inneholder i hvert fall et knippe punkter jeg har erfart kan hjelpe mye med å unngå å havne med et ødelagt bygning.