En af de negative tendenser, jeg har oplevet i de senere år, er, at vi som softwareudviklere er blevet mere kode- og produktcentrerede. Værktøjer som pseudokode, CRC-kort, mock-ups og lignende er næsten gået helt i glemmebogen og bliver sjældent brugt i den virkelige verden.
Vores værktøjskasse er simpelthen blevet for lille, og det minimerer hastigheden og kvaliteten af nye produkter og features.
90 procent læring - 10 procent produktion
Hvis vi ser på, hvor tiden i softwareudvikling bliver brugt, fylder selve produktionen af kode faktisk en meget lille del.
Det fik jeg lært på den hårde måde under min uddannelse, da en fil-server brød sammen efter en måneds arbejde på et projekt. Samtidig fandt man ud af, at backup'en heller aldrig havde virket. Det lykkedes os dog på et døgn (og ved indtagelse en del kopper kaffe og colaer) at genskrive det hele, og nogle dele blev endda bedre end den første udgave, for vi jo blevet klogere i mellemtiden.
Og her er netop hele pointen: Det, der bruges mest tid på i et projekt, er at lære nye ting. Det kan være at forstå domænet, finde den rigtige løsning på problemet eller løse begrænsninger i den anvendte teknologi.
Prototyping
Derfor er prototyper et vigtigt værktøj. For mig er en prototype et hvilket som helst værktøj, vi kan bruge til at lære noget om det fremtidige produkt.
Bildesignere bruger for eksempel stadig ler-modeller til at få den helt rigtige form på bilen eller skalamodeller for at teste aerodynamikken i en vindtunnel.
Også i softwareudvikling har vi været bedre til at bruge prototyper, for eksempel pseudokode for at forstå en algoritme uden at skulle fokusere på sprogspecifikke udfordringer, CRC-kort for at forstå relationer og ansvar mellem klasser/komponenter og mock-ups for at forstå, hvordan arbejdsgange skulle realiseres. Alle eksempler er teknikker, hvor man hurtig kan lære noget om løsningen.
Det er bare, som om vi er blevet mere kodecentrerede i de seneste mange år.
Det agile princip med tidlig og løbende afleveringer til kunden - som generelt er et godt princip - har måske været med til at gøre, at vi har fået for meget fokus på den næste aflevering, og dermed en misforstået tendens til at få kodet noget i stedet for at have fokus på at lære effektivt og minimere risici.
Tidlige udviklingsmodeller med fokus på risici, som f.eks. OOA/D procesmodellerne, havde måske en fordel ved, at man var mere bevidst om, hvor ens udfordringer lå, og så efterfølgende valgte det værktøj, som var mest effektivt til at reducere risikoen. Selv værktøjer som UML-diagrammer er gået fra primært at være en måde at lære på, til at være en måde at dokumentere en løsning.
Lappeløsninger
Problemet ved for en for kode-centreret udvikling er, at det - udover at være ineffektivt - kan have konsekvenser for kvaliteten af det produkt, der bliver skabt.
Når læring sker gennem produktet, er der stor risiko for, at den gamle viden efterlader spor i produktet - en del af det man kan kalde teknisk gæld.
I praksis er det sjældent, at man gentænker arkitekturen og sørger for, at interfacet stadig er konsistent, når man får ny viden eller skal lave nye features. Man forsøger lige at tviste den eksisterende løsning til også at håndtere den nye viden, og resultatet bliver en form for lap på lap, indtil et tidspunkt hvor man bliver nød til at starte forfra.
Konsekvensen er, at vi alt for ofte ikke leverer gode løsninger, men derimod kun acceptable løsninger. Hvis jeg skal være lidt provokerende, så kunne man også sige, at man skaber ikke Operahuset i Sidney ved at lave tilbygninger til en sportshal.
Omvendt er det endnu værre at bygge Operahuset i Sidney, når man finder ud af, at det er en sportshal, kunden har brug for. Så i de fleste tilfælde er vi nødt til at bruge en inkrementel og iterativ tilgang. Derudover har den inkrementelle tilgang også en masse andre fordele i forhold til at minimere andre risici, for eksempel i forhold til at finde kodefejl og integration mellem komponenter/systemer.
Brug hele værktøjskassen
Vi har brug for at minimere konsekvenserne af den læring, som sker i et udviklingsprojekt.
Nogle ting kan vi kun lære gennem produktet, men der er også mange ting, som vi kan lære billigere, hurtigere og med færre konsekvenser ved at bruge prototyper. Det kræver, at værktøjskassen for de fleste bliver udvidet, og at værktøjerne også bliver anvendt i det daglige arbejde.