Introduktion til Spec-driven-dev#
Denne post vedrører den syvende undervisningsgang i AIDA vi havde den 1/5-‘26, og vi havde om spec-driven-development. Hertil også Peter Naurs teori om programmering som teori-bygning, og hvordan specifikationer kan/bør bruges i AI-drevet udvikling.
Buzzwords/centrale begreber#
Feature spec#
En feature specification beskriver en funktionalitet før implementering.
En feature spec kan indeholde:
- Formål
- User stories
- Flows
- Acceptkriterier
- Begrænsninger
- Edge cases
Peter Naur#
Peter Naur var dansk datalog og introducerede idéen Programming as Theory Building.
Hans pointe er, at programmering ikke kun handler om kode, men om at udviklerne opbygger en forståelse om systemet. Forståelsen er hvad han kalder en teori.
Altså: Program ≠ kun kode Program = kode + menneskers forståelse
Theory building (view)#
Naur beskriver programmering som en proces, hvor udviklere opbygger viden gennem:
- Diskussioner
- Diagrammer
- Erfaringer
- Implementering
- Samarbejde
Det står i kontrast til Production View, hvor software ses som et produktionsarbejde.
Naur mener, at det vigtigste er den forståelse udviklerne opbygger undervejs.
Dette kan argumenteres for at være korrekt, eftersom at forståelsen for projektets behov og funktionalitet, kan være med til at skabe bedre resultater, da udvikleren forstår grundprincippet og behovet bag programmet, og bedre kan tilpasse det efter dette.
Realworld vs. code#
- Need to be able to see 1-to-1
Naur argumenterer for, at der skal være sammenhæng mellem virkeligheden og koden.
Man skal kunne se en relation mellem:
Virkelighed → model → kode
Hvis koden ikke længere afspejler problemet i virkeligheden, bliver systemet svært at forstå og vedligeholde.
Specs#
I forbindelse med AI, så siger Naur: lidt ja, men hvor meget?
- Det kan være godt at overveje det til dels, så claude ikke bare laver det hele. Og så man bedre kan se om det AI’en laver, faktisk overholder de behov der er til programmet.
Der er forskellige tilgange til spec-driven-dev:
Spec-first: Hele specifikationen laves først.
Fordel:
- Klar struktur Ulempe:
- Kan blive tungt
Spec-anchored Man bruger specs som støttepunkt.
Specifikationen guider arbejdet, men udvikles løbende.
Spec-as-source Specifikationen bliver selve kilden til implementering.
Dette er særligt interessant i AI-drevet udvikling, hvor kodeagenter kan generere kode ud fra specs.
Liv, død og genopstandelse:#
Naur beskriver software som noget der kan leve, dø og genoplives.
Tilblivelsen: Naur hævder at tiblivelsen af et program er det soamme som opbygning af teori hos programmørerne
Død: Hvornår dør et program: når de orignale theoryholders are no longer a part of the project
Genopstandelsen: Hvordan genopliver man et program: når man kan få fat i theoryholders fra det originale hold.
Oftest er 2. gang bedre, fordi man lærer af processen fra første.
Kan man forsvarligt blive ved med at patche, eller kan det betale sig at starte forfra.
Naur og metoder:#
Naur advarer mod blindt at følge metoder og processer.
Hvordan argumentere Naur for at man skal være på vagt overfor systemudviklingsmetoder, teknikker og principper?
- det er ikke metoden der laver teorien og programmet, det er programmøren der gør det, når de taler med kollegaer og laver diagrammer etc., det er handlingsorienteret proces der opbygger teorien. som han mener er vigtigt.
Metoder kan hjælpe, men de kan ikke erstatte forståelse.
Cockburn mener man godt kan bruge nogle ting fra XP, ie. at bruge en metafor til sit program, f.eks. en chatbot er en Personal Assistent.
Hvad har vi lært#
- At Peter Naurs tanker fra 1980’erne stadig er relevante
- At dokumentation ikke nødvendigvis er nok, der skal være forståelse bag dokumentationen
- At softwareudvikling handler om fælles forståelse
- At specs stadig er vigtige – måske endnu vigtigere med AI
- At kodeagenter kræver tydelige beskrivelser og acceptkriterier
Hvad var svært#
- At forstå forskellen mellem teori og dokumentation
Opsummering#
Spec-driven development handler ikke kun om dokumenter.
Det handler om at skabe en fælles forståelse af systemet.
Peter Naur argumenterer for, at den forståelse er det vigtigste aktiv i softwareudvikling – og det virker stadig relevant i en tid med AI og kodeagenter.