Hvad et computerspil fra 1985 lærte os om hurtigere prototyping

Et computerspil fra 1985 fandt for nylig vej til vores fredagshygge hos Webnorth.

En af vores seniorudviklere, Michał Gwóźdź, brugte omkring seks til otte timer på at genbygge Space Wars med inspiration fra et DOS-spil, som Simon huskede fra sin barndom. Resultatet blev et browserbaseret multiplayer-spil, hvor op til 20 personer kunne tegne deres egne rumskibe, skyde på hinanden og forsvinde ud i hyperspace med 5 % risiko for at eksplodere undervejs.

Det tog naturligvis ikke lang tid, før vores Pingtime Social udviklede sig til en lettere kaotisk Space Wars-turnering.

Michał byggede spillet med Node.js og WebSockets og brugte Claude til at sætte fart på dele af udviklingen. Vi bruger allerede AI som en del af vores udviklingsarbejde og har tidligere skrevet om vores tilgang til AI i softwareudvikling. I det her tilfælde var det interessante især, hvor hurtigt en eksperimenterende idé kunne blive til noget, man faktisk kunne bruge, teste og reagere på.

Det blev meget tydeligt, da vi begyndte at spille.

Med 20 rumskibe på samme skærm mistede folk konstant overblikket over, hvilket skib der var deres eget. I stedet for at skrive problemet ned til senere tilføjede Michał næsten med det samme en distress flare. Vi spillede videre, funktionen blev testet i praksis, og spillet blev forbedret, mens vi stadig sad og brugte det.

Det er netop her, hurtigere prototyping bliver interessant. Værdien ligger ikke kun i, at udviklingen kan tage færre timer. Det giver også mere plads til at afprøve idéer, som ellers måske aldrig var kommet længere end til en samtale.

Når det kræver mindre at teste en idé, kan man bygge en tidlig version, sætte den foran rigtige brugere og se, hvad der sker. Nogle idéer viser sig at være unødvendige. Andre åbner muligheder, som var svære at få øje på, før der faktisk var noget konkret at interagere med.

Den samme tankegang giver mening uden for eksperimenter som Space Wars. I custom WordPress-udvikling arbejder vi ofte med funktioner, workflows og interaktioner, hvor en tidlig version kan gøre det langt lettere at forstå, hvad brugerne faktisk har brug for. Hurtigere prototyping giver os endnu en måde at undersøge de spørgsmål på, før der bliver brugt for meget tid på den forkerte retning.

For tre år siden havde vi nok tænkt os om en ekstra gang, før vi brugte seks til otte timer på noget så eksperimenterende. I dag gør værktøjer, der accelererer udviklingen, den slags afprøvning lettere at forsvare.

Nogle gange fører det til en bedre tilgang til et kundeproblem. Andre gange opdager vi en teknik, der er værd at arbejde videre med. Og nogle gange ender det bare med, at 20 kolleger prøver at skyde hinandens tvivlsomt tegnede rumskibe ned en fredag eftermiddag.

Alle tre dele kan vi lære noget af.