"Min stemme har forladt mig, så der er kun mig i dag."
Det er en hæs Dan North, der grundet en forkølelse eller JAOO-konferencens fest aftenen før står på scenen i store sal i Århus Musikhus. Han skal fortælle om sit liv som agil arkitekt.
Den mere eller mindre bortløbne stemme afholder ham ikke fra at levere en medrivende og underholdende fortælling om sit liv som agil arkitekt / konsulent / shaman/ it-arkæolog.
Og fortælle kan han. Fortællinger er nemlig et meget vigtigt element i forståelsen af it-systemer.
Hvad er hulemaleriernes historie?
"Når man går i gang med at se på et eksisterende system, er det som at komme ind i en hule og se malerierne på væggene. Man tænker: Wow, hvad er historien bag det her," siger han.
Og det er her, fortællingerne kommer ind i billedet. De skaber forståelse for systemets opbygning.
"Der er altid en grund til, at systemerne ser ud, som de gør, og den historie findes ikke kun i kildekoden, dokumentationen og andre systemrelaterede ting. Hvert projekt har brug for en shaman, der kan fortælle historierne om, hvorfor it-systemerne ser ud, som de gør," mener Dan North og kaster sig ud i sin egen fortælling.
Hans fortælling består af erfaringer fra "et eller flere nødlidende projekter", han som konsulent har været med til at hjælpe på ret køl.
Softwaren afspejler din organisation
"Teknisk set var det SOA, der var gået galt. Klienter var koblet til services via WSDL, og der var en masse duplikeret kode i form af mange ens services. Samtidigt var der hundredevis af metoder på de mange services," forklarer Dan North.
Og kodeforståelsen blev ikke just hjulpet af, at xdoclet blev anvendt til at generere EJB-relaterede filer.
"De fik en hulens masse kode, som de kun anvendte en minimal mængde funktionalitet af," siger Dan North.
"Operationelt var det en kompleks, ustabil infrastruktur. Der blev anvendt EJB'er i en non-standard, gammel upatchet version af JBoss," beretter Dan North.
Softwaren var præget af Conways lov, der siger, at softwaren afspejler din organisation.
"Organisatorisk sad udviklerne i siloer. De talte ikke sammen. Det var en udpræget holdning, at alle de andre var idioter; "Jeg ved godt, hvordan tingene skal være, men det er håbløst, så jeg koncentrerer mig bare om min del af koden," fortæller Dan North.
Bras + bras = ?
Så hvad gjorde den agile arkitekt med hang til fortællinger?
Han lyttede - og lyttede. Da han var færdig med det, lyttede han en del mere.
"Det var vigtigt for mig at forstå, hvad der foregik, så jeg brugte meget tid på at tale med hver enkelt udvikler. Grundlæggende havde de faktisk alle sammen de samme gode ideer, de var bare holdt op med at tale med hinanden.
Planen var at opgradere til en nyere JBoss, men stort set anvende den samme arkitektur. Der skulle ikke laves gennemgribende ændringer, blot tilretninger.
"Det betød, at man havde noget bras, som man ville lave noget nyt bras ud af og så lægge det hele sammen til en endnu større bunke bras," siger Dan North, som indså det håbløse i situationen.
Han fik ledelsens opbakning til at starte en større renovering og gøre tingene rigtigt, da det i det lange løb ikke ville blive dyrere.
Sæt navn på den god idé, og den dør
Næste skridt var at ændre kulturen i gruppen.
"Jeg ville have dem til at tale med hinanden, så jeg foreslog stå-op-møder som i scrum- traditionen."
"Det har vi prøvet - det virker ikke," lød svaret.
Dan North fik dem til at prøve igen.
Det var tydeligvis en akavet situation. Udviklerne var uengagerede og lyttede ikke, når de andre fortalte om, hvad de havde lavet dagen før, og hvad de skulle i gang med. Det var først, når turen kom til dem, at de vågnede op og sagde: "I går lavede jeg det, i dag skal jeg lave det". Altsammen meget skabelonagtigt og på ingen måde dynamisk og værdifuldt.
Dan North indså, at det var en dårlig idé, at bruge stå-op-møder.
"I stedet fik vi bare en lille uformel snak om morgenen. Hvad havde folk gang i, og hvad gav mening at lave i dag."
Dan North opnåede præcis, hvad Scrums stå-op-møder er beregnet til, men tilsyneladende var selve ideen om stå-op-møder blevet stiliseret og kunstig i organisationen.
En lille psykologisk ændring gjorde en stor forskel:
Kald det kke stå-op, men sørg blot for en uformel snak med den enkelte.
Par-programmering - aldrig i livet - men jeg hjælper gerne
Det samme gjorde sig gældende med par-programmering. En enkelt udvikler nægtede at deltage i den slags. Her var det psykologiske fif, at en af Dan Norths konsulent-kollegaer over et stykke tid med jævne mellemrum spurgte udvikleren:" Hey, jeg kan ikke lige finde ud af det her kode. Kan du hjælpe?"
Selvfølgelig var udvikleren interesseret i at hjælpe og vise sine evner, så han var der med det samme. Det gentog sig mange gange.
Og så skete det. En dag sagde udvikleren: "Hey, kom lige herover og se. Jeg laver noget sej kode her."
Konsulenten kom over og var meget imponeret. Han foreslog endda et par enkelte ting, som udvikleren syntes var fint.
Det parløb udviklede sig, men der var selvfølgelig ikke tale om par-programmering - de hjalp blot hinanden.
Erkend fejl - det slipper kreativiteten løs
Dan North introducerede et Command patttern, da han anså det for et fornuftigt design pattern for det pågældende system.
Han tog fejl. Det var en fiasko og ikke et fornuftigt valg.
"Min fejlvurdering gjorde, at det - ganske utilsigtet - gav folk tillid til selv at eksperimentere. Frygten for at tage fejl forsvandt, da de så, at jeg dummede mig. De tænkte noget i retning af: "Når tech lead kan tage fejl, så kan jeg også eksperimentere," vurderer Dan North.
Vigtigheden af en overgangsarkitektur
Der var selvfølgelig også en del tekniske ting, der skulle ordnes.
EJB'er blev ikke længere anvendt. Der blev indført et
Service locator pattern, ligesom projekt build manageren Maven blev indført.
Begge dele var del af, hvad Dan North kalder en transitional architecture - en overgangsarkitektur.
"Maven skabte orden, men det er et uhyre at arbejde med. For at træde et skridt frem, er man nødt til at løfte et ben og et øjeblik balancere på et ben. Det fører dig fra a til b via en måske lidt ubehagelig position," mener Dan North.
Senere, efter der var kommet orden, blev Maven udskiftet med Ivy, som ifølge Dan North er meget venligere at arbejde med end Maven.
Med til historien hører, at projektet nu er gået tilbage til at anvende Maven.
"Der er andre folk nu. Historien er nok, at en åndssvag konsulent tvang os til at bruge Ivy, og først da man slap af med konsulenten, kunne man gøre det rigtige. Det er ok, det er deres fortælling."
Fortællingerne er med til at holde bevidstheden og forståelsen for systemerne i live.
