Med mindre du jobber med nyutvikling isolert på en grønn eng, så har utviklingsteamet trolig eierskap av programvare som allerede eksisterer.

Jeg vil peke på noe jeg syns er bra å prate mer om; at som utvikler har jeg et faglig ansvar for å bidra til å vedlikeholde den programvaren som teamet eier. Eierskap er ikke en varm fin følelse man får etterhvert som man har jobbet med en bit av noe — eierskap er noe man tar. Fordi det er en del av jobben.

Synlige og usynlige leveranser

Mange leveranser er synlige. Man kan peke på dem og vise dem frem. Kanskje noen utenfor teamet har ventet ivrig på å pakke opp og vise frem det nye i sin del av organisasjonen. Til sammenligning kan det være usynlig at «alt funker fortsatt som før», at et digitalt produkt IKKE ramler sammen, at noe IKKE lekker eller går opp i limingen — at vi kan bygge videre på det vi har, uten å måtte begynne på nytt fordi det vi hadde råtnet på rot. Alt sånt vil kanskje ikke være synlig utenfor teamet. Men stabilitet, sikkerhet og ansvarlig vedlikehold av programvaren vi skal forvalte — det er også en leveranse fra teamet.

Hva betyr vedlikehold?

Når teamet eier en applikasjon, kan det for eksempel bety at vi skal jobbe for å:

• sørge for at applikasjonen alltid kan bygges og deployes 🚀 (Solid prinsipp, fordi hvis det skulle oppstå noe akutt, så er det ikke da vi vil sloss med et brukket bygg eller en defekt pipeline)
• investere tid i å bli kjent med appen for å være i stand til å debugge når feil skjer
• legge til rette for at kjennskap til ulike deler av kodebasen spres mest mulig
• skrive dokumentasjon, og oppdatere dokumentasjon
• sikre oppetid og følge med på varsler om potensielle problemer
• oppdatere avhengigheter noenlunde fortløpende 🚂 (Neida, ikke hver eneste minor bump. Ja, det kan være gode grunner til å velge vente med de oppgrateringene som begynner ligne en migrering. Men det er skikkelig kostbart og kjedelig å late som om dette toget ikke ruller.)
• spesielt vurdere sårbarheter fra varsler merket critical eller high 🔥
• håndtere eventuelle varsler om eksponerte hemmeligheter
• vurdere risiko i applikasjoner som håndterer personopplysninger
• bruke og stadig forbedre loggingen 📊 (ikke for stort volum, logger som gir mening, justere på log levels, kunne reagere når noe dukker opp, kunne aktivt bruke loggene som sikkerhetsnett)
• ha et forhold til antall replikas vi kjører og skalere ressurser som minne/cpu
• ha postmortems på teamet for å sammen lære av feilsituasjoner 🎓
• skaffe oversikt over potensielle feilsituasjoner, hva skjer når xyz feiler og spre kompetanse på å fikse det, er det noe som kan forebygges? trenes på i en brannøvelse? 🧑🏻‍🚒
• standardisere teknologivalg utifra hva fagmiljøet vårt velger
• men også eksperimentere!
• skrive tester selv om det ikke er nyutvikling på gang
• både slette kode og forenkle kode når man kommer forbi noe 🧹

Og hvis en applikasjon ikke leverer nok verdi til at teamet tenker vi skal vedlikeholde den — ja, da er det på tide å prate om hva som skal til for å skru den av.

— Elisabeth