Jeg har netop registreret mig til GOTO København 2019. Måden jeg forbereder mig, er ved at smug-kigge på talerne via deres tidligere videofilmede talks. Ofte vil jeg vælge en lidt bedre taler over et lidt bedre emne, hvis der er konflikter. Jeg har fundet ud af, at det er sådan jeg får mest ud af en konference.
Den første konflikt i GOTO København-programmet, som jeg skal have løst er mellem Adam Tornhills “Prioritizing technical debt as if time and money matters” – et emne jeg ofte bliver konfronteret med – og Michael Brunton-Spall med “Does agile make us less secure?”, som bestemt også er et interessant emne. Efter at have hørt begge de to taleres tidligere talks (youtube er en guldgrube), vil jeg give pointene som mest engagerende taler til Michael og pointene for bedste emne til Adam.
Nu siger min tommelfinger-regel, at jeg skal høre Michael, men jeg er desværre stadig meget i tvivl. Adams tidligere talks har været tunge på brugbare analyser bygget på real-world kode. Michael er en sikkerhedsekspert som har set lyset i de agile principper. Jeg tror, jeg vil bryde min egen regel og lytte til Adam. Jeg kender godt de agile principper og selv om specielle briller, såsom sikkerhed, bestemt er interessant at kigge med, så er det mindre sandsynligt at det er meget ny information. Adams foredrag forventer jeg til gengæld, jeg kan lære rigtig meget af.
Hotspots og normalization of deviance
Jeg fandt nedenstående fantastiske video med Adam fra GOTO Berlin 2017 om et lignende emne. I den giver han et overblik over trends i hotspots i kodebaser generelt og uddyber, hvilke metrikker, der egentlig kan fortælle os noget om kodebasen. Her kan jeg især godt li’ hans indsigt at det ikke kan betale sig at gøre det hele alt for kompliceret; antal kodelinjer er faktisk et sigende mål. Ofte gør vi det mere kompliceret end det behøver at være.
En anden vigtig anekdote er om “normalization of deviance” baseret på Challenger-launch katastrofen. Hvis vi vænner os til dårligdommene i vores kode/hverdag, så risikerer vi at det bare sander mere og mere til. Adam foreslår, at vi i det mindste måler det, så vi kan være opmærksomme på problemet. Bliver det bliver værre over tid?
Conways lov
Conways lov bliver også nævnt, og jeg er fan.
Den siger:
…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
M. Conway
Som en der ofte beskæftiger sig med de bløde ting i en organisation såsom software teams, er det godt at blive mindet om at der er en direkte sammenhæng med kodebasen. Det betyder også at vi selvfølgelig bør involvere udviklere/arkitekter, når det handler om hvordan vi organiserer os i teams.
Statisk kodeanalyse kan sige mere om os som organisation end man umiddelbart tror!