Høydepunkter fra SDD Conf London

Høydepunkter fra konferansen dag 1

"This software sucks!" av David Wheeler

Tirsdag morgen var vi samlet i The Pit, i en kinosal under bakkenivå hvor David Wheeler holdt keynote. Mye av poenget David Wheeler trakk fram i sin innledning var hvordan interaksjonen mellom bruker og system er diktert av språk, og hvordan dette er en begrensning man må hensynta. Mennesket er i utgangspunktet et sosialt vesen, noe vi har vært siden steinalderen, så vi interagerer med omverdenen som sosiale dyr. Dette gjelder også når vi bruker en PC og datasystemer! Når vi treffer andre, er det naturlig å møte hverandre med ett vennlig “Hei! Hvordan har du det?”, og dette er noe vi forventer av et datasystem også. Da er det ikke særlig vennlig å få slengt en cookie-banner i trynet hver gang man går inn på en nettside, og etterpå et dusin pop-ups med “Subscribe now!” eller “Vil du delta på en kort spørreundersøkelse?”.

Ettersom idéen om et konsept er begrenset til en persons oppfatning av konseptet, blir også språket en barriere i formidlingen mellom personer. Vi som lager programvare har ofte et konsept vi ønsker å formidle, men brukerens oppfatning kan raskt være noe helt annet enn det tiltenkte.
 

“Zen of Architecture” av Juval Löwy

Dette innlegget kan ikke sies å være noe annet enn minneverdig. Etter en introduksjon hvor Löwy hevder å være verdens beste arkitekt, fortsatte en tirade om at vi, tilhørerne, ville havne i helvete ettersom vi fulgte de etablerte metodene innenfor arkitektur og design. Derimot hadde Löwy løsningen i et konsept hvor man deler opp systemet basert på volatilitet framfor funksjon. Den ‘livsendrende’ løsningen til det hele kunne man få om man valgte å følge de seks påfølgende innleggene han skulle ha. Selv om han har et noe unorsk selvbilde, så har han også en historikk som viser til en del suksess, så kanskje er det noe i det hele?

Høydepunkter fra konferansen dag 2

“Identifying Architectual risk” av Mark Richards

I prosessen med å identifiser hvorvidt en arkitektur er riktig må man definere hvilke risiko som er relevante. Ved å ta de viktigste kravene fra forretningen og oversette til kapasiteter i arkitekturen får man forretning til å ta eierskap til disse. Ut i fra dette kan man sette opp en matrise med kapasiteter mot kontekst (gjerne sub-domene). Deretter identifiserer man risiko og kvantifiserer denne i matrisen fra null til ni. Summerer man rader og kolonner, får man et bilde av hvilke kapasiteter og kontekster som har høy risiko, og man kan legge inn tiltak for å redusere disse. Når dette er gjort er det viktig å legge inn måleparametre som kan si noe om denne risikoen endrer seg over tid når systemet er i bruk. 
En måte å gjennomføre denne prosessen på er Risk Storming. Her vil man invitere rundt fem personer med erfaring med arkitektur eller kjenskap til systemet til å se over arkitekturen å gi sin vurdering av risiko. Deretter kjøres en samarbeids sesjon hvor man blir enige om en felles forståelse av risiko. Så kan man sammen gjøre en vurdering om tiltak for å minimere risiko. I etterkant måler man kapasiteter for eksempel med fitness functions for å etterprøve tiltakene.
 

“Granularity and communication in Microservice architecture“ av Neal Ford

I dette innlegget ble vi presentert for ulike taktikker for å bestemme granularitet for en tjeneste. Et sett med teknikker for oppdeling og sammenslåing ble trukket fram som måter å bestemme hvilket nivå en tjeneste kunne deles opp. Ved oppdeling ble det nevnt; funksjonalitet, volatilitet, skalerbarhet, feiltoleranse og tilgangsrestriksjoner. Ved sammenslåing ble det nevnt; transaksjoner, dataavhengigheter og flyt og koreografi.

Det ble så dratt fram et utfallsrom som bestod av tre dimensjonere; synkron/askynkron kommunikasjon, orkestrert/koreografert koordinering, og atopisk/eventuell konsitens. Ut ifra disse dimensjonene kunne man definere et sett med transaksjonelle saga patterns og dynamisk quantum koblinger, hvor hver av de hadde et sett med fordeler og ulemper.
 

“The cash value of technical debt” av Jules May

Jules May presenterte her en matematisk modell som skulle kunne brukes for å si noe om når man kunne være kvitt teknisk gjeld. En forutsening man sier er at all koding tilfører en viss mengde tekninsk gjeld. Hvordan denne andelen måles er vel heller noe usikkert, men utgangspunktet synes å være at man etter en viss tid har generert så mye teknisk gjeld at det tar tilsvarende lang tid å rette opp denne uten å tilføre ny verdi. Det som derimot synes å ha en vesentlig innvirkning i positiv forstand er å jevnlig legge inn sprinter (hver 4.) hvor man refaktorerer for å ta hånd om opparbeidet teknisk gjeld.

Høydepunkter fra konferansen dag 3

“If considered harmful” av Jules May

I 1968 ble det publisert et brev fra Edsger Dijkstra hvor han forklarte hvorfor de fleste bugs i programvare stammer fra GoTo-statements, og han appellerte for at GoTos burde bli fjernet fra programmeringsspråk. Nå har vi kanskje ikke lengre GoTo-uttrykk i moderne språk, men vi har for- og while-løkker, if-statements og andre deklarasjoner som gjør at vi hopper fra sted til sted ved kjøring av kode. Å forstå den statisk deklarerte koden som vi skriver er noe helt annet enn å forstå hvordan den oppfører seg ved dynamisk kjøring.

Ofte har vi if-uttrykk som sjekker på en betingelse ett sted i koden, og et annet sted, kanskje i en annen fil, har vi et annet if-uttrykk med samme betingelse som fører til noe annet. Disse to stedene ligger langt fra hverandre, men siden de sjekker på samme betingelse har de to stedene noe til felles. Dette skaper et ormehull mellom to kode-blokker som egentlig er knyttet til hverandre, men ligger på forskjellige steder i koden. Disse ormehullene skaper kompleksitet, avhengighet, dårlig vedlikeholdbarhet og bugs.

I foredraget ga Jules May oss tre teknikker for å ikke lage slike ormehull. Blant annet kan man ha lokale beslutningstrær med switch-uttrykk for ulike tilstander et objekt kan være i, eller så kan man bruke C# down-casting factories.
 

“Understanding complexity” av Toni Petrina

Hvorfor er det slik at det er så komplekst å skrive programvare? Toni Petrina ga oss innsikt i ulike typer kompleksitet, hvordan oppdage dem og hva vi kan gjøre med det. Et symptom på kompleksitet er gjerne høy kognitiv last, hvor man må ha mange variabler i hodet samtidig for å forstå hva som skjer i en kodefnutt. Et annet symptom er at en kodeendring ett sted fører til endringer mange steder.

Vi skiller hovedsakelig på to typer kompleksitet; essensiell og utilsiktet. Førstnevnte stammer fra oppgavens natur. Enkelte ting er komplekse fordi vi lever i en kompleks verden, og det er det lite å gjøre noe med. Utilsiktet kompleksitet derimot er den vi lager selv; teknisk gjeld, feil valg, dårlige kodepraksiser etc. Når en kodebase vokser over tid er det viktig å huske å dekomponere i mindre biter, slik at hver bit blir forståelig. En hovedregel er at en modul skal være generell og dyp, med et lite grensesnitt mot omverdenen.

Så hva kan vi si?

Alt i alt er det en omforent oppfatning blant oss som deltok at denne konferansen er både lærerik og et godt gjennomført arrangement. Selv om hvert innlegg hadde varighet på 90 minutter, var de fleste engasjerende og interessante nok til at dette var passende lengde. Hvert innlegg var merket med ferdighetsnivå, og selv om det kanskje ikke alltid stemte, hadde de fleste noe man kunne ta med seg videre. Åtte forskjellige spor gjorde også at det var mer enn nok å velge i. Vi kan varmt anbefale denne konferansen til andre som er interessert i arkitektur og programmering.

Serveringen var også helt innafor med varm lunsj og pudding hver dag, selv etter full English på hotellet først.

London var en super vertsby for konferansen. Det er enkelt å komme seg hit fra Trondheim, selv om enkelte av oss måtte kjenne på makspuls og melkesyre i beina etter å ha løpt igjennom mellomlandinger.

Hver konferansedag hadde program frem til kl. 17:30, så det ble ikke mye tid til sightseeing på kveldstid. På kveldene dro vi ut på restaurant og spiste oss gode og mette, og det ble tid til å fordøye og diskutere de forskjellige foredragene hver av oss hadde vært på.

Vi rakk til og med en tur til sør-London, eller i hvert fall 500 m sør for Themsen, og traff på en annen delegasjon fra Norge, som vi slo oss sammen med for en hyggelig middag på en uteservering i 14 varmegrader, i motsetning til 20 grader de andre dagene. Etter en tur langs ‘the beer mile’ i jakten på autentisk britisk manuell-pumpet øl, fant vi også ut at mye er stengt på en onsdag, men heldigvis ikke alt.

Takk for turen!