Softwareudviklerne dropper prototyper - men det går ud over kvalitet og hastighed

Klumme: Prototyping er langsomt ved at forsvinde fra softwareudviklernes værktøjskasse, og det er en skam, for der er meget vigtig læring at hente. I stedet anvendes ofte korte iterationer, men prototyper kan hjælpe med at skabe billigere og bedre produkter.

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.


Ytringer på debatten er afsenders eget ansvar - læs debatreglerne
Indlæser debat...

Computerworld
De 30 største danske it-virksomheder: Her er antallet af ansatte - og hvor mange penge, der bruges på løn
Top 100: Computerworld har nærstuderet årsregnskaberne fra 499 danske it- og televirksomheder og kan her bringe listen med de 30 største arbejdspladser. Se antallet af ansatte og få et indblik i, hvor mange penge virksomhederne bruger på løn til medarbejderne.
CIO
Bare glem alle advarsler og alarmklokker: ”Din smartphone får ikke virus”
Sikkerhedsfirmaer advarer jævnligt om, at almindelige menneskers smartphone står pivåbne for virus og malware. Men ifølge en kendt sikkerhedsekspert findes det stort set ikke i Danmark.
Comon
Oversigt: Her er de bedste Android-smartphones der kan købes i Danmark
Det vrimler med spændende Android-smartphones på markedet. Vi har samlet en oversigt over de bedste Android-telefoner, du kan købe herhjemme netop nu.
Job & Karriere
Se listen: Disse it-folk bliver ansat på stedet - cheferne skriger efter helt bestemte it-kompetencer
Der er en markant mangel på it-folk med helt bestemte kompetencer samtidig med, at it-cheferne er i gang med at øge bemandingen i it-organisationerne. Se listen med de mest efterspurgte it-kompetencer netop nu.
White paper
Mobility - her er de aktuelle udfordringer
Hvad med sikkerheden? Mobility-bølgen fejer igennem danske virksomheder, og der er masser af muligheder og faldgruber. Sikkerheden halter, men det kan der gøres noget ved. Produceret af Computerworld.dk i oktober 2014.