Keynote

Russ Olsen holdt den bedste keynote jeg nogensinde har hørt. Titlen var “To the moon” og var fortællingen om rum kapløbet – “Et svært, men arbitrært mål, med en arbitrær deadline”. Lige som når vi laver software. I sit gribende foredrag fortalte Russ om hvordan NASA greb udviklingen an ved at “prøve alt der var tænkeligt i parallel og håbe på at det alt sammen passede i sidste ende” – lidt lige som når vi udvikler software. Keynoten fortsatte med at fortælle om Apollo 11 missionen til Månen, både som han oplevede den fra sofaen sammen med sin far, samt hvad der skete undervejs. Russ gennemgik missionen, inkl. alt hvad der gik galt og hvordan astronauterne håndterede og løste problemerne – og ikke mindst hvordan ground control håndterede alle de svære situationer. Hvis jeg skal opsummere hvad jeg lærte fra det, så var der tale om en utrolig høj grad af tiltro mellem ingeniørerne og astronauterne. Da navigations/styre computeren meldte fejl 1202 (computeren er overbelastet), sagde en af ingeniørerne, der var medansvarlig for computeren og softwaren, “ignorer fejlen” og alle accepterede det. Da Armstrong senere slog navigations/styre computeren fra før tid, var der ikke nogen der stillede spørgsmål. De stolede på ham og gav kun nødvendig information tilbage så som “1 minuts brændstof tilbage”. En af grundene til at der var så stor tiltro, var at ingeniørerne var toppen af poppen, de var meget dedikerede og samtidig havde de en høj grad af autonomi (kan træffe beslutninger på egen hånd). Astronauterne var udvalgt ved tidligere at have håndteret ekstremt svære og farlige situationer uden tab af liv og materiel. De bedste af de bedste. Der var mange andre rigtige gode pointer, men en af de afgørende for mig var at “alt kan lade sig gøre”. Hvis man med så kort en tidsplan og svær en opgave kunne lykkedes med at sende folk til månen og få dem hjem igen, så kan alt andet også lade sig gøre. Det er spørsmål om at tro på missionen, hyre de bedste, give dem autonomi og sikre en høj grad af dedikering og tiltro til hinanden. Resten er “bare” teknik 😉

Setting a Good Example – How to improve your SbE, BDD and ATDD artefacts af David Evans

David Evans gennemgik Specification by Example (SbE), Behaviour Driven Development (BDD) and Acceptance Test Driven Development (ATDD), hvor fokus er på at Gode eksempler hjælper os med forstå de generelle regler (klarlægger kravene), Eksempler bliver til test og Tests verificerer kravene. Eller sagt på en anden måde: Kravene er en slags regel og tests er en slags eksempel. Mine take away points er:

• En specification skal forklare hvad der skal testes, IKKE hvordan de skal testes
• SbE, BDD og ATDD er mere end bare test. De starter livet som specifikationer, snart bliver de til test og med tiden bliver de til dokumentation.
• Det er vigtigt at skelne mellem kort livet materiale (stories, tasks, acceptance criterias, cards) og længere livet materiale (specifikationer, acceptance tests, levende dokumentation). Vi bør kun beholde de sidste og “brænde” de første.
• Der er flere konkurrerende kræfter i værk mellem specifikationen (der bør være kortfattet), testen (der bør være komplet) og dokumentationen (der bør være sammenhængende og selvforklarende)
• SbE, BDD og ATDD følger mere eller mindre alle “Given, When, Then…” specifikations formen. Balancer “Given” og “Then” delen. Sørg for at “When” delen er kortfattet. David anbefaler at starte med at skrive “Then” delen, da det bedre sikrer at “Given” delen ikke indeholder noget der er irrelevant for “Then” delen. Han kalder dette “Time glas” formen.
• Husk eksempler og mod-eksempler for at tydeliggør reglen (positive og negative test)
• Til alle dem der løber ind i argumentet at “test sløver udvikling ned”, anbefaler David at sammenligne det med at “bus passagererne også sløver bussen ned”. Det ville være meget hurtigere for bussen, hvis den ikke skal have passagerer med eller skulle stoppe ved holdestederne. Pointen er at “det er ikke bussens hastighed der er pointen!”. Software udvikling er også meget mere end hastigheden. Det er det softwaren er bygget til at kunne løse der er pointen. Uden tests har vi reelt intet bevis for at vores software kan løse det, den er bygget til at kunne løse.
• Den indsats det er værd at bruge på at skrive tests, afhænger af den værdi vi tillægger tests.

Big Data, Bad Analogies af Mark Madsen

Mine take away points fra denne snak var: Accidential complexity og teknisk gæld skyldes

• Intentionelle og ikke-intentionelle beslutninger, både på kort og lang sigt
• At man baserer beslutninger på for få data eller svagt grundlag, f.eks. vælger mange at de skal bruge NoSQL fordi MySQL ikke performer (argumentet var bla. at MySQL er en dårlig database). Det kunne jo være at man brugte en for dårlig database eller man brugte den på den forkerte måde.
• Mange vælger data storage teknik uden at tage hensyn til tilgangs mønstre (Read/Write, Read Only, Read Mostly), Forudsigelighed, Selektivitet, Latens tid, Concurrency, Data model, opgave størrelse. OLTP, BI, Datawarehouse har meget forskellige behov for samtlige disse parametre.
• Valg af teknologier kan koste dyrt på f.eks. storage. Antaget et quorum på 3 i Cassandra bliver de samme data gemt 3 gange. Skal data bruges af Hadoop, kræves det at data bliver kopieret til Hadoop HDFS, hvor quorum typisk også er 3. Til sidst kan man have behov for at benytte en overbygning til Hadoop (jeg har glemt det eksempel han brugte) som også benytter et quorum på 3, hvorfor ens data ender med at være gemt 9 gange alt i alt, hvilket kan ende med at blive dyrt i storage og kopierings tid.
• Hoved pointen var at indenfor Big Data har vi IKKE behov for Best practices, vi har behov for at lære af “Worst failures”.

Responding in a timely manner – Microseconds in HFT or milliseconds in web apps, its all the the same design principles af Martin Thompson

For dem der ikke har hørt Martin Thompson før vil få sig en overraskelse. Han er utrolig skarp ved hvordan man bygger højt performende trading systemer med lav latens tid (< 1 ms). Martins pointe er, at de teknikker man benytter til at sikre lav latens tid i high frequency trading systemer er de samme som man benytter til at bygge web applikationer der svarer hurtigt (det er blot skalaen der er flyttet).

Nøgleord er:

• Asynkron besked håndtering (som er helt på linie med min holdning)
• Beskeder håndteres i en pipeline med queues i mellem
• Det er vigtigt at sørge for bounded queues (køer med en begrænset længde) – også kendt som back pressure – se her for mere
• De algoritmer du benytter er rigtig vigtige (ja vi skal tilbage til skole tiden og lære om O(n) igen). Brug hellere tiden på at lære om algoritmer og data strukturer, f.eks. Tries, i stedet for frameworks, da frameworks lever kort tid, men algoritmer og strukturer lever for evigt.
• Martin fortalte også om Amdahls lov, Littles Law og Universal Scalability Law.

What is a Reactive Application Part I og Part II af Todd Montgomery, Kresten Krab Thorup, Viktor Klang og Martin Thompson

Langt hen af vejen blev dette foredrag en gentagelse af Martins foredrag. Der blev taget udgangspunkt i det Reactive Manifesto.

Mine take away points er:

• Del arbejdet op i batches og pipelines så der ikke opstår contention
• “Synchronous RPC is the crack cocaine of distributed programming”
• De 3 regler for modstandskraft (resilience) i en løsning: 1. Isoler, 2. Gør fejl observerbare (som beskeder), 3. Genstart

Der var mange gode diskussioner i 2. halvdel, som desværre er svære at gengive her.

Afslutnings keynote – Our Responsibility to Defeat Mass Surveillance af Martin Fowler og Erik Doernenburg

Argumenter som “jeg har ikke noget at skjule” blev hullet med argumenter som. Måske ikke i dag, men hvad med om 30 år? Alt biver gemt og kan misbruges senere. Og hvad med dem der har noget skjule  den gode sags tjeneste, f.eks. journalister eller græsrods bevægelser? Hvad sker der hvis det er nemt for korrupte politikere, mv. at finde ud af hvad journalisterne/mv. har planer om. For at sikre sig, må journalister og andre græsrødder benytte krypterede emails. Men det får dem til at stå ud fra alle de andre ikke krypterede emails. Derfor var opfordringen at flere bør begyndr at kryptere deres emails, så det billede kan blive ændret.

Sidst kom Martin og Erik med en opfordring til alle os udviklere. Næste gang vi står overfor valget om at vælge “profit over privacy” vs “lidt mindre profit og mere privacy”, at vi foretager et bevidst valg (uden at sige at det må andre tage sig af). Vi har som udviklere en meget bedre mulighed for at ændre billedet – med den evne følger i følge Erik og Martin også et ansvar.