Slipp skippertaket
Skippertaket har en lang og god tradisjon i norsk skipsfart og studentliv. Jeg vil tro at også resten av verden kjenner til konseptet, selv om de kanskje ikke har noe tilsvarende ord. For sjøfolket var det en naturlig del av arbeidslivet, som ble preget av lange rolige perioder til havs, fulgt av korte intense arbeidsøkter mens de var i havn. Å ligge i havn er kostbart og lite produktivt. En fraktebåt tjener bare penger når den frakter noe.
Da jeg var student (for noe som føles som en mannsalder siden nå), var ikke skippertaket før eksamen noe vi planla eller ønsket, men var likevel like uungåelig og forutsigbart som at sola går ned om kvelden. Jeg har hørt at det skal finnes steder der sola aldri går ned på kvelden, og at det finnes studenter som leser jevnt mellom hele semesteret, men jeg har til gode å se det (enda familien på farsiden kommer fra Troms).
Selve ideen om et “prosjekt” er i seg selv et skippertak
For oss i IT-bransjen er heller ikke skippertaket noe ukjent fenomen. Hvem har ikke vært med på lange dager rett før en leveransedato, feilrettingsdugnader eller testsprinter. De fleste prosjekter preges ofte av en lang periode med planlegging, utprøving og famling — for så å avsluttes med en hektisk periode hvor all overflødig funksjonalitet kuttes til beinet og presser ut et produkt som ikke ligner helt det man så for seg å lage. Selve ideen om et prosjekt er jo i seg selv et slags skippertak. For å sammenligne med skipsfarten kan man si at daglig drift og vedlikehold er som å være ute på sjøen, mens prosjektene er de som ligger i havn og losser funksjonalitet om bord.
Man kan jo da spørre seg om dette er en lur måte å jobbe på.
Selve prosjektmodellen kan man nok argumentere for er nokså uungåelig, gitt at økonomien ofte styrer slik. Men også her finnes det de som sier at de klarer å unngå det, og her har jeg faktisk også litt erfaring. For min del var det en god erfaring. Men det blir anekdotisk og utenfor mitt fagfelt, så jeg skal ikke gå noe mer inn på det her. Der jeg kan si noe mer om skippertakets lumske natur er innen programmering og arkitektur.
Testdekningsdugnad: kritiske feil ryddes unna, de med lavere prioritet ligger i årevis
Et typisk tilfelle er når teamlederen får en rapport som viser testdekningen for en kodebase som er et langt stykke under de 80–90% av hva deres valgte metodikk (les: testdrevet utvikling), lover. En testdekningsdugnad må til. Et skippertak som hever denne statistikken til de høyder som den bør være på.
Er annet typisk tilfelle er når antall registrerte uløste feil i bugtracker’en blir faretruende høy. Som regel rydder man unna de mest kritiske feilene så fort de dukker opp. Men feil med lavere prioritet kan bli liggende i årevis. Og sånt akkumuleres da de gjerne ikke forsvinner av seg selv. Et klassisk eksempel er fra Microsoft sitt godt kjente Excel. Der godtas faktisk datoen 29.02.1900, selv om år 1900 ikke var skuddår… Feilen har vært der siden Excel ble laget, og jeg tror ikke den går bort av seg selv…
Feilrettingsdugnaden — Når antall feil møter en smerteterskel
Når antallet feil møter en smerteterskel hos de som følger med og har ansvar for det, utløses også et annet kjent skippertak – feilrettingsdugnaden. Gjerne med en premie til den som retter flest feil.
Teknisk gjeld er gjerne en ting du hører om når du kommer ut i arbeidslivet. Diskusjonene går ennå om hva dette egentlig er for noe, om det er mulig å unngå, og om det egentlig er noe å bry seg om. Tror dog de fleste er enige i at det noen ganger kan bli for mye teknisk gjeld. Noen analyseverktøy mener de kan måle dette, og noen utviklere fortviler ofte over det når de må gjøre endringer på et system. Begge deler kan utløse skippertak for å fjerne utysket.
Vi må fikse de underliggende problemene!
Det kan argumenteres for at resultatene av skippertak for alle de tre eksemplene er positive, og at de ikke gjør noen skade.
Jeg vil si de gjør mer skade enn godt.
For det første gjør de at du slipper unna med å ikke fikse de underliggende problemene. Disse opphopningene av problematisk kode kommer ikke av seg selv. De kommer fordi utviklerene har en eller flere grunnleggende feil i måten de jobber på. Hvilket betyr at en stund etter skippertaket så finner du deg selv i behov for å måtte gjøre flere skippertak. Dette stjeler av tiden du burde bruke på å levere ny funksjonalitet til brukerene.
For det andre er det begrenset eller ingen læringseffekt av å gjøre dette, fordi konteksten den feilaktige koden ble skrevet i, er tapt eller vanskelig tilgjengelig. Enten fordi du retter opp i andres kode eller fordi du ikke husker hvorfor du gjorde som du gjorde. Uten den konteksten er det vanskelig å gjenkjenne situasjonen feilen oppstod i. For eksempel i tilfeller hvor du må skrive en test for kode som ikke er dekket av tester. Hvorfor ble det ikke skrevet tester da koden ble laget? Ble det uteglemt? Ble ikke metodikken testdrevet utvikling brukt? Visste ikke utvikleren hvordan testbar kode skulle lages, og dermed ikke klarte å skrive tester? Har noen slettet testene fordi de var plagsomme eller vanskelige å vedlikeholde? Grunnene kan være mange og mangfoldige.
Det kan være mange årsaker til at man skriver kode med lav kvalitet, men får man ikke tilbakemelding om dette kjapt, forsvinner læringspotensialet.
Den andre ulempen med tapt kontekst er risikoen for å innføre nye feil. Ofte kan noe som ser ut til å være feil ett sted, være kompensert for et annet ikke så synlig sted. Dette er jo ofte kode som kjører fint i produksjonen, men med noen mindre betydelige feil vi vil rette opp i. Hvis vi ikke vet hvorfor noe ble implementert som det ble, kan vi risikere å innføre en ny større feil når vi forsøker å fjerne en liten feil.
For å slippe skippertakene må vi endre måten å jobbe på
Det er mange tiltak du kan gjøre for å bedre kodekvalitet, betale teknisk gjeld, øke testdekning, og minske antallet feil. Kodegjennomganger, verktøy for kodeanalyse under bygging, metodikker som testdrevet utvikling, automatiserte systemtester, osv. Felles for disse er at de gir utvikleren kjapp tilbakemelding mens konteksten fremdeles er tilgjengelig.
Når det kommer til testdrevet utvikling (TDD) så må du passe på at du faktisk gjør dette. Veldig mange sier de gjør dette, uten at de faktisk skriver testene før de skriver koden. Ofte blir tester slengt på etter at endringen er implementert, dersom en har tid. Det fører sjelden til god testdekning, og du ender gjerne opp med å skrive tester som befester feil i koden. En indikasjon på at TDD ikke blir utført riktig er at du bruker testdekning som et mål. I utviklingsprosjekter der utviklerene gjennomfører TDD er ikke testdekning et relevant mål, og de kan da heller konsentrere seg om å skrive gode tester som også feiler når koden endrer seg på feilaktig måte.
Parprogrammering, hvor utviklerparet bytter på å skrive feilende test og kode som får testen til å ikke feile, er en effektiv måte for å sørge for at TDD blir utført på en god måte.
Rydd opp etter deg — gamle synder forsvinner ikke av seg selv
Ulempen med disse tiltakene er at de hjelper lite på det som allerede er gjort. Har du kommet i en situasjon der du føler at skippertak er nødvendig, er det en fattig trøst at utvikleren får rask tilbakemelding på den koden som skrives i dag. Hva med alle de gamle syndene? De forsvinner jo ikke av seg selv?
Anbefalingen er at vi lar oss inspirere av speiderbevegelsen og en sørafrikansk erkebiskop, og finner frem tålmodighetskremen.
Speiderregelen sier at du skal etterlate deg en leirplass minst like ryddig som da du kom. For utviklere betyr dette at når du endrer på en kode (med liten testdekning, rotete kode, småfeil) så rydder du litt opp i den koden i tillegg til å gjøre den endringen du skulle gjøre. Dette vil føre til at for hver endring du gjør, får du litt mindre grunn til å gjøre skippertak.
Problemet er ofte at en leirplass kan være like rotete som en elefant er stor. Hvordan spiser du denne elefanten kan du da lure på? Dette svaret har blitt gitt av Desmond Tutu: “En bit om gangen.”
God planlegging, små leveranser og raske tilbakemeldinger er nøkkelen
Skippertakene rett før leveranse er det lite du kan gjøre med på utviklernivå, da dette ofte skyldes mangelfull planlegging. Men gjør du leveransene små og produksjonsetter de hyppigere, er det mindre sjanse for å estimere feil, samtidig som utviklerene får raskere tilbakemelding på den koden de leverer. I dagens systemutviklingslandskap er det ikke lenger noen grunn til å samle opp mange endringer i store leveranser. Nivået på verktøy for automatisering av alle trinn i bygge- og leveranseprosessene er nå så høyt at du kan levere og produksjonssette endringer flere ganger hver dag. På den måten kan du jobbe på en smidig måte og gjennomføre hver endring isolert.
Tips til mer lesning: Hvordan gjør du prosjektene mer smidig?
Selv for helt nye systemer eller større endringer har vi i dag verktøy og metoder for å levere små deler av funksjonaliteten, såkalte MVP’er (minimum viable product) som også kan tilgjengliggjøres for en undergruppe av brukerene. Det vil hjelpe deg til å holde kompleksiteten på leveranser nede, samt at forsinkelse på én endring ikke vil påvirke de andre. Du kan dermed unngå å havne i den sedvanlige situasjonen der du må gjøre skippertak mot slutten av en periode.
Selv om vi neppe kan unngå å måtte ta i et ekstra tak i ny og ne, håper jeg du, kjære leser, nå ble overbevist om å slippe skippertaket.
