FAGKVELDCynefin, DI-feature toggling, prosjektledelse og funksjonell programmering
Fagkvelden gikk av stabelen for andre gang i år med fullt program 14. mars. Lokasjonen var igjen på Kulturhuset etter sist gangs suksess. ITverket er fryktelig glad i shuffleboard.
Cynefin
Ole Andreas presenterer Cynefin
Først ut var Ole Andreas som fortalte om Cynefin (uttalt KUN-iv-in, selvfølgelig). Det er et rammeverk han ble introdusert for og inspirert av under Domain Driven Design Europe-konferansen han deltok på tidligere i år. Rammeverket er opprinnelig laget for ledere og andre decision-makers for å ta beslutninger, men kan også brukes til å endre synet på leveranser, målsetninger og avgjørelser innen systemutvikling.
Før man starter med utvikling må man finne frem til hvilke av Cynefins fem domener problemstillingen ligger i, slik at man best mulig kan finne frem til en god løsning. Disse fem er; simple, complicated, complex, chaotic, og "centre of disorder".
By Snowden - File:Cynefin framework Feb 2011.jpeg, CC BY 3.0
Et eksempel på lærepenge fra presentasjonen: Scrum har et fastsatt idealresultat man kjører iterasjoner mot. Alle "vet" dette, og dette målet ansees som den beste løsningen uten at den nødvendigvis er det. I realiteten er det kun en av mange mulige løsninger som vi bare har bestemt er den beste. Woah!
Her var en god takeaway at det er greit (og til og med anbefalt) å begi seg ut på et Dive into Chaos, men prøver du for hardt å putte en problemstilling i et enklere domene enn det egentlig er, så sitter du fort i saksa etter en Collapse into Chaos. Spoiler alert: der vil man ikke ende opp.
Feature toggling via dependency injection
Kato presenterer feature toggles.
Nestemann ut var Kato, som holdt en presentasjon om feature toggles. Eller som han selv klassifiserte den: en presentasjon av feature toggles - done right. Her fortalte han om hvordan man kan klargjøre skillet og redusere avhengigheten mellom deploy og release ved bruk av kode som aktiverer/deaktiverer funksjonalitet ved hjelp av feature toggles. På denne måten kan man ha kontinuerlige leveranser av nye features til produksjon, men “aktivere” dem når man vil ved å skru disse featurene på når man måtte ønske, potensielt lenge etter de har blitt levert. Stilig.
Kato luftet derimot sin misnøye rundt manglene i eksisterende implementasjoner for feature toggles som han fant mens han undersøkte konseptet. Så i kjent stil, lagde denne nerden sin egen måte å gjøre det på. Vi fikk innblikk i hvordan man kunne gå vekk fra direkte modifikasjoner representert ved if-else-setninger, slik:
if (feature.isEnabled) {
DoNewStuff();
}
else {
DoOldStuff();
}Har man slike sjekker rundt om i koden, fører det som regel til at man bør regresjonsteste all gammel funksjonalitet for å kunne introdusere ny. En burde heller gå en annen rute: feature toggles via dependency injection (Kato™). Han viste hvor bra dette fungerte med en råflott demo av en nettside som gikk fra vise “Wrong value” til å vise “Right value”! (Ok, han er kanskje ingen UX-designer, men det tekniske var enestående).
Prosjektledelse
Øyvind snakker om prosjektledelse
Etter en matpause var det Øyvind sin tur. Han jobber som prosjektleder, og ettersom dette er et nytt satsingsområde i ITverket, var det både hensiktsmessig og interessant da han presenterte hvordan hverdagen hans så ut. Her fikk vi innblikk i hvilke oppgaver han møter og områder han er ansvarlig for, som å definere scope og hindre den fryktede “scope creep”, overholde prosjektets budsjett og stå ansvarlig for leveranser. Det ble også tydelig hva behovene for å ha en prosjektleder er, og kanskje tydeligst av alle disse var at en prosjektleder fungerer som et bindeledd (og ikke minst megler) mellom Business og IT. Det er det vel ingen som kan nekte for verdien av.
Hva vi har lært: en prosjektleder står i høy risiko for å bli den ene personen både Business og IT kan peke på som syndebukk. Øyvind er en modig mann. Go Øyvind!
Funksjonell programmering med Kotlin
Sist, men ikke minst, hoppet vi med begge føtter (og hender og resten av kroppen) inn i det mer tekniske med Tom Adams presentasjon om funksjonell programmering. Hos hans oppdragsgiver er de åpne for nye ting, som gir rom for nye teknologier. Tom Adam forklarte at ettersom de var ute etter å bevege seg over mot funksjonell programmering, ble Kotlin er bra valg ettersom man får til eksempel immutability gratis med på kjøpet. Å få til det samme med den eksisterende teknologien hos oppdragsgiver i Java var en langt mer tungvinn prosess. Vi fikk se kodesnutter og fikk notert ned en hel mengde nye begreper som skal googles!
Absolutt ingen betvilte Tom Adams kunnskaper om funksjonell programmering etter denne presentasjonen. Ingen.
Les mer om Tom Adams egen vei til Aha-opplevelsen med funksjonell programmering i innlegget hans her
Alt i alt var fagkvelden definitivt en suksess! Interessen og engasjementet for innholdet i presentasjonene var så høyt at vi mistet shuffleboard-avtalen vår med 40 minutter. Sier litt.
