Tiger Team eller Tidy Team - hvem vil du helst skal lage og forvalte systemene dine?

Stig jobber i Kodemaker og elsker å programmere, men tenner mest der han må ta tak i forretningsmessige problemstillinger og løse disse ved hjelp av nye arbeidsprosesser understøttet av teknologi. 

Uavhengig av bransje, så har softwareutvikling mye til felles. Med seg på laget har man ofte ulike typer mennesker, og systemutviklere kommer i alle fasonger, med ulike fokus og fremgangsmåter. Denne bloggposten tar et dypdykk ned i utviklerrollen, og vi blir kjent med Tiger Trym og Tore Tidy. De er begge dyktige, men har diamentralt forskjellig fokus. Hvem vil du helst skal lage og forvalte systemene dine? Og må man egentlig velge? La artikkelen hjelpe deg i gang med refleksjonene, samt gi deg noen verktøy på veien. 

Systemutviklere kommer i alle fasonger. Tiger Trym og Tore Tidy er to veldig ulike utgaver. De er begge dyktige, men har diamentralt forskjellig fokus.

Tiger Trym er ekstremt opptatt av å komme under huden på brukerene. Hva er det de lever av? Hvordan jobber de? Hvilke problemer sliter de med?

Han er rask til å sette seg inn i det som er viktig, og blir etterhvert flink til å utfordrer brukerene på de riktige stedene. Trym har dårlig tid og tar i bruk alle triks og snarveier som gjør at han klarer å gjennomføre hyppige avklaringsrunder med kjørbare kodesnutter og produksjonsnære data.

Rammeverk med magiske anotasjoner slukes på høykant under mottoet - det som gir fart er lov. Andre utviklere er ikke så glad i å ta over koden til Trym. Den er ofte vanskelig å forstå og er full av avhengigheter som er snurpet sammen med strikk og binders. Brukerene derimot, de elsker Trym. Han er interessert i det de holder på med, leverer raskt og viser tydelig at han forstår hva butikken driver med.

Trym vil ha fart for raskt å komme under huden på brukerens behov.Jo raskere han kan levere ny funksjonalitet - jo fortere tetter han sine egne og andres kunnskapshull.

Tore Tidy derimot skal ha kontroll på teknologien. Han har tidligere brent seg på bruk av magiske rammeverk og utdaterte avhengigheter. Det gav litt fart i starten, men ble etterhvert en tvangstrøye som ble strammere og strammere. Nei Tore liker best det han lager selv.

All innføring av avhengigheter gjøres etter grundige evalueringer og med så løse koblinger som mulig.

De andre utviklerene ser veldig opp til Tore. Han lager solid og velstrukturert kode, som er lett å sette seg inn i og videreutvikle. Brukerene forstår at Tore er flink. De ser at han er en nøkkelperson i prosjektene han deltar i, men av og til lurer de litt på om han egentlig bryr seg om det de holder på med.

Tore hater kaos og kan ikke fordra mas om fart eller tidsfrister. God kode og smarte løsninger krever grundighet som ikke passer med “full gass”. Det går fint å bygge et hus - stein for stein, mener Tore.

Hvem vil du ha med deg i et prosjekt?

Alle vil jo ha fart, men ingen vil ha kaos. Hvem har riktige verdier? Trym eller Tore?

Software Engineering Radio har bra podcaster. De har et herlig, inspirerende og lærerikt format. Det er ikke alt jeg forstår, eller er enig i, men det er en fin kilde til inspirasjon og refleksjon. I episode 598 ble verdiene i AMMERSE presentert. Der beskriver Jonathan Crossland verdier, som han mener er grunnleggende innen systemutvikling. Verdiene er gradert etter “modenhet”.

Det første modenhetstrinnet består av verdiene: Reachable and Solvable - eller fritt oversatt: Forstå de viktige problemstillingene og finn løsninger.

Dette er jo Trym i et nøtteskall. Forstå - løs - forstå - løs og så videre. Så fort noe er løst - så er det bare å kaste seg over nye utfordringer.

Trinn to består av verdiene: Minimal, Maintainable and Environmental - som i betydning elegant, enkelt og gjennomtenkt uten å innføre unødvendig kompleksitet.

Det øverste nivået består av Extensible som i betyningen: fremtidsrettet.

Dette er jo Tore - gjennomtenkt og fremtidsrettet.

Sånn ser “modenhetstrappa” ut:

En slags behovspyramide der grunnverdiene forstå og finn løsninger, er fundamenet for igjen å bygge smarte løsninger. Jeg er ikke så sikker på om det er så viktig å legge inn “støtte for fremtiden”. I mange tilfeller holder det lenge, at det som faktisk er laget, er lett å forstå og trygt å gjøre endringer i. Da klarer du å håndtere nye krav, når de kommer.

Trym står på trinn en, Tore står på trinn to, men han står på skuldrene til Trym.

Fyll servietten

Systemutviklingsprosessen kan sammenlignes med å tegne et portrett av en virklighet som er tåkelagt. Du skal begynne å tegne, men du ser ikke motivet.

Denne tåken kan oppleves som:

• Brukerene er usikker på målet.
• Utviklerne er ukjente med domenet.
• Beste praksis for å oppnå mål er ikke definert eller ukjent
• Prosesser og hendelser er uklare
• Diskusjoner går i sirkler og vi sliter med å ta gode beslutninger.
• Vi peker på at andre må avklare

Skal vi sette Tore i gang med å avdekke pixel for pixel nede i et hjørne eller skal vi se om Trym klarer å blåse bort tåka slik at vi får bedre oversikt?

Jeg skrev tidligere om hvordan jeg tenker når jeg skal forstå et nytt domene. Her har jeg en enkel “metode” som får plass på en serviett.For å lette på sløret, må vi jobbe oss gjennom boksene i servietten ved hjelp av noen brukerhistorier. Det er jo fristende å starte på toppen og jobbe seg nedover, for så til slutt å implementere det vi har funnet ut. Dette fungerer ikke i praksis. Vi må lage noe som fungerer, med produksjonsnære data for så å fasilitere gode diskusjoner.

Diskusjoner, der vi gradvis fyller boksene med innhold, i lys av brukerhistoriene vi jobber med. Vi må se de røde trådene i fra målsetning til kjørbare kodesnutter. Vi må få snøret i bånn, før sementen størkner rundt misforståelser og gale forutsetninger. Ikke over alt, men rundt noen viktige brukseksempeler som angriper fra litt ulike synsvinkler.

Da vil tåken forsvinne, og vi sitter igjen med en ganske så god skisse av motivet.

Et godt overblikk over motivet gjør det lettere for Tore Tidy å bygge solide strukturer der det trengs, og fleksibilitet der det er nødvendig. For det er jo dit vi vil. Smarte løsninger som er enkle og samtidig trygge å gjøre endringer i - klare for fremtiden.

Hva er poenget?

Både Trym og Tore har viktige egenskaper for å lage god programvare.

• Trym er flink til å lære og forstå, samtidig som han lager prototyper som løser de riktige problemene.
• Tore er grundig og systematisk og lager produkter som tåler tidens tann.

I starten av prosjekter, er folk ofte forventningsfulle, motivert og i modus til å tenke ut nye løsninger.

Vi må passe på at vi utnytter dette momentet. Avtal en rytme med avklaringsrunder. Gi brukerene hjemmelekse mellom hver økt og sørg for at de føler at det er “nå det skjer”.

Mitt poeng er at denne fasen ofte krever Tigeren i oss. Vi må absorbere mye informasjon raskt og omdanne det til kjørbar kode for verifisering.

Det beste er jo selvfølgelig å gjøre ting riktig og optimalt med en gang, men for all del - ikke la brukerene sitte å vente, mens vi koser oss med tekniske utfordringer.

• Dersom vi ramler ned i et teknisk hull som det er fristende å forsøke å komme seg ut av … la det vente. Det er ikke sikkert det er viktig likevel.
• Dersom det klør i fingrene etter å refakturere noen kodelinjer for å få de litt mer ideomatiske … la det vente. Det er ikke sikkert kodelinjene overlever et par iterasjoner likevel.

Misforstå meg rett. Det er mange tekniske problemstillinger som bør få oppmerksomhet tidlig, men igjen - ikke la brukeren vente mens du koser deg med teknologi.

Og til slutt - når alt “fungerer” så er det ikke automatisk et ferdig produkt. Vi kan ikke nøye oss med å bare ha funnet en løsning. Vi må sørge for at den er elegant, enkel og gjennomtenkt uten unødvendig kompleksitet. Da er vi rustet for fremtiden.

Tekst av: 

Stig Melling 

Utvikler