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...

CIO
Ekspert er ikke i tvivl: Det er nødvendigt at indføre helt nye KPI’er i virksomhederne
Interview: Mange virksomheder er nødt til at indføre helt nye KPI'er, der skal bruges til at måle og styre den digitale indsats. Gartners toprådgiver Peter Søndergaard forklarer, hvorfor det er nødvendigt - og hvordan du kommer i gang.
Comon
Test af Razer Phone: Hvem havde troet, at et gaming-brand ville lancere årets mobiloverraskelse?
Test: Razer har lanceret sin første smartphone, og mens det langt fra er en smartphone for alle, så indeholder den alligevel nogle innovative ideer, som vi kan lide.
Job & Karriere
Dansk it-virksomhed indførte fire-dages arbejdsuge: I dag er sygefraværet rekord-lavt og direktøren har tabt sig 13 kilo
Interview: Great Place To Work kategori-vinderen IIH Nordic har indført en fire-dages arbejdsuge og taget et opgør med forstyrrende storrums-kontorer og en frustrerende mailkultur. I dag er medarbejderne gladere end nogensinde før.
White paper
Er din virksomhed (måske) på vej ud i skyen? … her er tre mulige strategier og alle de vigtigste overvejelser
For langt de fleste virksomheder er cloud en uundgåelig del af fremtiden. Men hvordan skal man gribe det projekt an? Dette whitepaper fra EG fyldt med værdifulde input til de virksomheder, som står på tærsklen til at tage beslutningen - analyser, refleksioner, opmærksomhedspunkter og anbefalinger, som kan være en støtte i overvejelserne og undersøgelsen forud for beslutningen.