Når hastighed er en konkurrence parameter.

En af de farer der lurer når man konkurrere på hastighed i software udvikling er hvad der i software arkitektur kaldes inkonsistens – men hvordan kan det være? Der er flere parametre man kan bruge hvis man skal have et overblik over om man har en god software arkitektur. Er software arkitekturen fleksibel, er den forståelig og er den til at finde og rette fejl i? Hvis man skal kunne svare ja til de 3 ting, er det nødvendigt er man har en konsistent omgang med sine begreber. Og det at lave software er bland andet at definere klynger af funktionalitet med et afgrænset men præcist og veldefineret potentiale for at bidrage til en samlet brugeroplevelse. Noget af det sjove er navngivning, hvad skal klyngen hedde? Den skal have et navn, for man skal kunne tale om den, ellers kan man ikke kommunikere effektivt omkring sin software arkitektur, og kan man ikke det, er man ude af stand til at definere sin organisation. Hvis man ikke kan navngive sine klynger er der noget der tyder på, at der er noget inkonsistent inde i midten af sin klynge af software funktionalitet – ansvarsområdet er blevet for bredt om man står med et multiværktøj, som hverken er en rigtig tang eller kniv. Og det er svært at sige om et multiværktøj er godt – for hvad mener man, kniven eller tangen? – det bliver svært at kommunikere. Det bliver også svært at finde fejl, af to grunde: For det første, af dem simple grund at man ikke kan kommunikere, og derfor ikke sige hvor fejlen er, den er i klyngen som har et navn der ikke dækker hvad den kan, for det andet, hvis der er to fejl er sandsynligheden for at den er i klyngen uden navn større, fordi den indeholder mere funktionalitet end den burde, og derved skal to mennesker til at rette i den samme kode. Det er svært, som at male et maleri to mennesker på samme tid. Det kræver koordination og sætter hastigheden ned fordi det umulig gør parallel udvikling.

Inkonsistens er noget der er nødvendigt at kunne kommunikere omkring sin software arkitektur, men det er i lige så høj grad noget med brugen af de klynger som har et veldefineret ansvarsområde. Og brug er noget folk med forstand på human computer interaction har forstand på. Og her en kobling som er værd at ligge mærke til. Nok bruger designere meget tid på at gøre ting smukke og brugervenlige, men det er præcis de samme egenskaber softwareingeniører leder efter når der skal laves softwarearkitektur. Klynger, klasse, moduler er brugsgenstande, som skal bruges i en kontekst, i dagligdagen og som skal være til gavn for mennesker, præcis som brugergrænseflader.

Brug og kontekst består af to ting, menneske og maskine adaption, og den sociale organisation hvori der arbejdes med software. Vi mennesker bruger sproget og vores kognitive evner som levende væsner når vi iagttager verden, også når det gælder software. Software ingeniører bruger begreber som klynger, klasser, moduler, interfaces, lag delt arkitektur og andre mønstre når vi skal beskrive hvordan softwaren vi bygger er tiltænkt at virke. Designere bruger lang tid på at gøre en genstand brugbar, så den passer til forståelse vi mennesker har umiddelbart når vi ser genstanden. Det er det der gør genstanden let at bruge og vi bliver glade fordi den virker som vi umiddelbart tror. Det samme er gælder software, en klynge af software klasser skal være navngivet så vi umiddelbart forstår hvad den kan, have et interface gør at klyngen fungere som vi umiddelbart tror. Og hvorfor? – der er tid at spare, det gælder i human computer action om at designe et interface sådan at det passer til den opgave brugeren står overfor. Og at grænsefladen hjælper brugeren med at udfører den opgave. På den måde reduceres fejl i betjeningen, opgaven bliver udført hurtigere og man får glade brugere der kommer igen. Igen gælder det samme for software, når en programmør sidder med en samling af klynger og skal lave ny funktionalitet, har det menneske et problem. Den samlede mængde af software håndtag der er til rådighed skal hjælpe den programmør med at løse opgaven, også så mængden af fejl reduceres.

Der er en vis mængde psykologi i det, for vi har med mennesker at gøre. Især mentale modeller er vigtige i software, fordi vi kommer med erfaring i bagagen og skal løse en software opgave, og hvis vi møder noget der udfordrer vores mentale model bliver vi skeptiske. Vi laver som regel to forskellige modeller når vi arbejder med software: En strukturel model og en funktionel model. Den strukturelle model er den vi laver når vi laver kasser, klynger osv. Den fortæller os hvad systemet består af, og hvordan strukturen er i systemet. Den funktionelle er hvordan vi bruger ting. De fleste ved ikke hvordan den strukturelle model er af en lommeregner, men de kan godt bruge den, for de har en funktionel model. Software arkitektur skal beskrive begge modeller. Når vi laver software som en organisation, bygger i sammen den mentale model i real tid. Det er derfor det er vigtigt at de er konsistens i software arkitekturen, og at der er kommunikation. Hvis ikke arbejder vi ikke sammen, og vi forstår noget forskelligt ved det samme. Den bedste måde at organisere det er ved at gøre det simpelt. Præcis som et dørhåndtag, det er simpelt alle ved det hvordan det skal bruges. Når noget bliver komplekst bruger vi refactoring, for hele tiden at arbejde med at gøre tingene simple.

Vores udviklingsmodeller skal tage højde for denne opbygning af den mentale model, ellers går det galt. Vandfalds modellen som jo for tiden bliver brugt som eksempel på det man aldrig må bruge, tager højde for det. Der er indbygget tid til at bygge den mentale model op, modsat Scrum hvor der ingen tid er, ej heller til at kommunikere den. I Scrum arbejder vi med hvad jeg vil betegne som halve systemer fordi der er en stor focus på vertikale features, og ikke focus på de lag som arkitekturen skal rumme for at kunne rumme de klynger af software der skal til for at løse det samlede problem. Scrum bliver let begrebstomt, og enhver tanke om at lave begyndelsen til en klynge af software moduler, kan for let slås ihjel med ”står det i backloggen?”, ”er det målet for dette sprint?”.

Romere og Lean

Sådan sagde Asterix og Obelix igen og igen, men faktisk var der mindst en enkelt mand der havde fat i noget omkring Lean. Cicero sagde; Quis? Quid? Ubi? Quibus? Auxiliis? Cur? Quomodo? Quando? Som oversat betyder: Hvem? Hvad? Hvor? Hvorved? Hvorfor? Hvordan? Hvornår? Disse blev siden kaldt de 7 filosofiske grundbegreber.

Matthew May har skrevet om Lean, “Lean requires a precise understanding of value - the Who, what, when, where, how, and why. Og den skarpe kan jo se at han mangler en, nemlig Hvorved?. Den vender vi tilbage til.

Toyota lavede en prius på 15 måneder, og det er et stykke software på hjul. Toyota bruger Lean, og konkurrere på hastighed, altså hvor hurtigt de er i stand til at producere noget nyt, som er helt nyt og markeds skabende.

At konkurrere på hastighed, er svært i software udvikling. Fordi det der slår hastigheden ihjel er, komplexitet, inkonsistens og overload. Og software er komplext, så hvad gør man? - man holder det simpelt. Og det gør man ved at have en fælles infrastruktur i sit software projekt. En fælles arkitektur som er forståelig, fælles navne konvention, fælles værktøjer.

Det starter som regel godt, for software er jo ikke komplext fra begyndelsen, når der ikke er skrevet en eneste linie. Det kan godt være at kravende er svært og komplekse, men softwaren er det ikke endnu. Det sander til efterhånden som man kommer mere og mere funktionalitet på, fordi ens arkitektur ikke er i stand til at bære det. Der er ikke tænkt igennem som et framework der virkelig skal understøtte de ændringer der er nødvendige for at nå i mål med sit produkt. Derfor kræver software som regel hvad vi kalder refactoring. Det byder sig selv, at har man meget af det, er man lige vidt. Hvis man hver gang der kommer et enkelt nyt krav skal skrive det meste om, er er igen noget der tyder på at ens arkitektur ikke er tænkt igennem. Derfor er fleksibilitet i software arkitektur vigtigt, men pointen er at det framework som skal bære den fleksibilitet ikke kan ændres undervejs. Der skal være tilstede fra begyndelsen, for hvis det ændres får man inkonsistens og dermed bliver den begrebs verden man har bygget op undervejs i projektet hele tiden revet ned - og det gør at man er så langt fra at være agile og lean som man overhovedet kan være.

Scrum mennesker vil nok råbe, og sige - jamen det er perfekt for Scrum er jo netop en process, som er i stand til at håndtere ændringer. Pointen er bare at det er ligegyldigt, hvis ikke din software arkitektur er i stand til at rumme ændringer. Så kan det godt være din process kan, men din software kan ikke også er det håbløst. Hvis du vil have noget der over tid til stadighed kan ændres, skal du have arkitektur der understøtter det og ikke en process der understøtter det. Hvis du kun har processen sander det til, og det er præcist det som Scrum gør igen og igen når det møder virkeligheden.

Setbased design, er et koncept fra Toyota. Det handler basalt set om at have så mange strenge at spille på hele tiden så muligt. Det vil sige, hele tiden arbejde med flere løsninger på engang og vente så længe så muligt med at tage beslutninger om hvilken der skal bruges. Det kræver selvfølig at man har folk nok, men prøv lige og tænkt på følgene eksempel fra som Mary poppendieck, hev frem da hun talte om “competing on basis of speed” ved google. En der laver software til printere, har et problem. Han marketing folk siger at hvis de skal sælge printere i stort antal skal de have “red eye reduktion”. Det lyder simpelt nok, red eye reduktion er en kendt teknik, men her ville de gerne have en automatisk red eye reduktion så den selv var i stand til at detektere om det var nødvendigt uden menneskelig indblanding. Manden der skulle lave det havde to algoritmer, en god, og en dårlig. Den dårlige kunne let implementeres og på den aftalte tid, den gode tog længere tid og krævede flere ressourcer. Nu var manden jo softwareingeniør, og vi har jo hang til gode algoritmer, men han viste ikke hvor han skulle få ressourcerne fra. Mary sagde så, jamen hør nu her, du siger til mig at hvis i har den her teknologi kan i sælger mange flere printere, også så spørger du mig om hvor du skal få ressourcen fra`? - jamen hvad er alternativet!. Vil i sælge mange printere, eller vil i ikke?.

At arbejde med flere løsninger på samme tid, kræver frihed. Frihed til at lege og blive specialist, fordi at det er netop det der gør, at man er klar når kravet kommer. Det kræver altså det vi engang kaldte udvikling!. Ikke bare at udvikle løsninger til kunden men også at blive specialist i på sit område, så man er foran kunden. Det er en organisation der er i stand til at håndtere ændringer.