10 tidløse tips for bedre IT-systemer

Sindre jobber i Kodemaker og er en allsidig utvikler som er lidenskapelig opptatt av å lage gode brukeropplevelser og verdiskapende IT-løsninger. I sine 14 år som konsulent har han erfaring fra mange små og store prosjekter i både privat og offentlig sektor. Sindre har forenklet hverdagen til Mattilsynets inspektører og gjort vektestimering av oljeplattformer til en lek. Akkurat nå hjelper han leger og sykepleiere over hele landet med å få rask tilgang til dataene de trenger for å behandle pasientene sine.

Det er vanskelig å lage virkelig gode IT-systemer. Ofte blir resultatet bare helt OK, og i verste fall kan det nye IT-systemet oppleves som et kostnadssluk heller enn det verdiskapende verktøyet man hadde sett for seg på forhånd. 

I denne artikkelen deler Sindre 10 nyttige erfaringer fra sin tid som utvikler. Teksten er primært rettet mot utviklere, men her vil det være gull å finne for alle som er involvert i utvikling eller forvaltning av digitale løsninger.

1. Å lage de aller beste løsningene krever god domenekunnskap

Vi kan ikke forvente å kunne lage gode arbeidsverktøy for helsepersonell uten å forstå deres oppgaver, arbeidshverdag og behov. Det holder heller ikke at noen få personer i teamet har denne kunnskapen; vi gjør alle stadig valg hvor utfallet påvirkes av hvor godt vi kan domenet. Utviklere med god domenekompetanse vil kunne sparre med fagpersoner rundt funksjonalitet og prioriteringer. Lange utredninger blir overflødige. Og produktene vi lager vil løse brukernes faktiske behov, og bidra til å forbedre noen sin hverdag.

2. Det er utrolig hvor mye et lite team med dyktige folk kan få til

“For mange kokker…” er relevant i programmeringssammenheng også. Samle noen få utviklere, designere og domene-eksperter i et rom, og nyt magien som oppstår. I mine mest effektive oppdrag har vi vært to utviklere i teamet. Liten kommunikasjons-overhead, begge har kontroll på hele kodebasen, og beslutninger tas lynraskt.

3. Vi bør se systemene våre i bruk

Det skaper et sterkt inntrykk å se en bruker knote frem og tilbake med funksjonalitet man trodde var selvforklarende. Å observere sluttbrukere i aksjon vil garantert gi mange aha-opplevelser (og mange nye oppgaver på tavla). Og jeg tror at det gjør oss til bedre utviklere. Vi utvikler empati for menneskene bak “bruker”-begrepet. Kanskje tenker man seg litt ekstra nøye om når man gjør den neste endringen i brukergrensesnittet.

4. Det lønner seg å være nøye med språk og begreper

Det har vært begrepsforvirring i alle prosjekter jeg har jobbet i. Det kan være at man i teamet bruker flere begreper for samme “ting”. Det kan være at vi utviklere rett og slett bruker et domene-begrep på feil måte, eller at vi kommer opp med egne ord der det allerede finnes et etablert språk i domenet. Og ikke minst kan folk med ulik bakgrunn i forskjellige roller tillegge et begrep ulik betydning. Dette kan gi relativt små utslag, som for eksempel at kode er vanskelig å lese, men det er heller ikke uvanlig at unøyaktig bruk av begreper fører til større misforståelser og dårlig kommunikasjon. Det kan koste mye tid og penger. Jeg tror at vi kan minimere disse problemene ved å sette oss godt inn i domenet vi jobber med, og ved å ha et mer bevisst forhold til språket vi bruker i koden og i dagligtalen.

5. “Hvorfor?” er et kraftig verktøy

De fleste av oss har blitt bedt om å lage en knapp. Bak ønsket om en ny knapp ligger det gjemt et behov. Ved å grave oss bakover, vil vi til slutt avdekke det grunnleggende behovet. Da kan vi utviklere bruke våre problemløsningsferdigheter til å sparre rundt alternative løsninger. Kanskje ender vi opp med en automatisert løsning som alle er enda mer fornøyde med?

6. Det er vanskelig å slå tavle og tusj

Å tegne på tavle er et veldig effektivt kommunikasjonsverktøy — om man så skal lære bort noe, skape en felles forståelse, eller samarbeide om å løse et problem. Informasjon fester seg bedre når den visualiseres, og aktiv bruk av tavle holder godt på oppmerksomheten. Og ikke minst er det en naturlig felles arbeidsflate hvor flere kan drodle og tegne samtidig.

7. Eksplisitt > implisitt

Noen ganger har vi konsepter i koden vår som gjemmer seg godt. La oss si vi har en pappeske med høyde, bredde og lengde. Flere steder i koden multipliserer vi disse, og resultatet brukes blant annet til å finne ut hvor mange pappesker som får plass i en varebil. Multiplikasjonen skjuler et konsept i domenet — som til og med kan virke ganske sentralt. Ved å innføre volum som et eksplisitt konsept, vil vi øke lesbarheten i koden, og kanskje også oppleve mer fruktbare diskusjoner med fagpersonene rundt oss.

8. Komplisert forretningslogikk trives best i isolasjon

I mange kodebaser blandes forretningslogikken sammen med lagring av data, API-detaljer og annen infrastruktur. Ved å isolere domene-koden, reduserer vi den kognitive belastningen som kreves for å forstå logikken. Dette er viktig, da mange utviklere skal lese, forstå og endre logikken i løpet av systemets levetid. I tillegg blir det veldig enkelt å skrive enhetstester for det som tross alt er hjertet i applikasjonene våre.

9. Kode bør organiseres etter funksjonalitet

Kodebaser har ofte pakkestrukturer som gjør det tungvint å navigere i koden. dto, db, modell og controller hjelper oss ikke så mye når vi skal få oversikt over en ny kodebase, eller når det skal innføres en ny betalingsmåte i nettbutikken. Derfor er jeg stor tilhenger av å ha pakker som bestilling, betaling og levering på toppnivå. Betaling kan igjen inneholde for eksempel faktura og kortbetaling. Da blir det åpenbart hvor den nye betalingsmetoden passer inn. En annen gevinst med en slik inndeling er at avhengighetene blir tydelige: bestilling har avhengigheter til betaling og levering, betaling har kun eksterne avhengigheter osv.

10. Å skrive kode er bare en del av jobben vår

Likevel er det i all hovedsak programmeringsspråk, biblioteker og rammeverk det fokuseres på i jobbannonser, i artikler og på konferanser. Det virker som at vi av og til glemmer at jobben vår også består av å lære nye domener, dele kunnskap med andre, løse problemer, samarbeide i team, håndtere konflikter, organisere og bryte ned arbeid, prioritere, strukturere informasjon, og mye mer. Her er det mange erfaringer og egenskaper som er nyttige å ha som utvikler — som kanskje ikke helt får den oppmerksomheten de fortjener.

Tekst av:

Sindre Grønningen

Problemløser