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
Med ny iOS-opdatering vil du selv kunne slå udskældt batterifunktion fra på din iPhone
Apple har sænket ydeevnen på ældre iPhones for at få batteriet til at holde længere, men nu fortæller Tim Cook, at du i fremtiden selv kan slå funktionen fra.
CIO
Vestas’ CIO stopper: Torben Bonde trækker sig efter 19 år på posten
Interview: Torben Bonde har været CIO i Vestas i de seneste 19 år og har været øverste chef for mange hundrede it-medarbejdere i en global it-organisation, men nu er det slut. Her fortæller Torben Bonde om fremtidsplanerne.
Comon
LG stopper al udvikling af LG G7: Begynder helt forfra få måneder før lancering
Ifølge et velanset koreansk investormedie har LG’s CEO beordret fuld stop på udviklingen af LG G7 og starte forfra
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
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.