Någon ska läsa det på morgonen

I en offert jag läste stod det att en agent kunde köra ett antal nätter i veckan. Utveckling som pågår medan teamet sover. Resultatet väntar när de kommer in.

Det är inte påhittat. Det är verklig praxis idag. Och skälet till att det måste gå via API i stället för personliga abonnemang är dessutom korrekt: en abonnemangslicens får inte schemaläggas eller köras parallellt. Den delen av resonemanget var välinformerad.

Det som inte stod någonstans var vem som läser resultatet på morgonen.

Vad som faktiskt händer i ett välskött upplägg

Agenten arbetar inte i blindo. Den kör mot testsviten, mot linters och mot bygget, itererar tills allt går igenom. Det är maskinell verifiering innan någon människa ser något.

Resultatet landar sedan som ett förslag på en egen gren, utanför det som är i drift. Ingenting driftsätts av sig självt.

Och sedan kommer granskningen. En människa läser, förstår och godkänner. Det är den verkliga grinden. Den ligger på morgonen.

Kedjan är alltså: automatiserad körning, automatiserad verifiering, mänsklig granskning, och först därefter sammanfogning.

Därför flyttas arbetet snarare än försvinner

Nattskiftet tar inte bort utvecklarens arbete. Det byter innehåll i det.

Mindre tid går åt till att skriva och mer till att läsa. Och att granska kod man inte själv har skrivit går långsammare än att granska sin egen, för man måste först rekonstruera vad den försöker göra innan man kan avgöra om den gör det rätt.

Det är i sig inget problem. Det är en helt rimlig arbetsfördelning, för många team en bättre.

Men det har en konsekvens som sällan syns i en offert: om automatiken gör leverantören snabbare ska det märkas i timmarna. Gör det inte det betalar beställaren två gånger. En gång för verktyget som ska ge effektiviseringen, och en gång för de timmar effektiviseringen skulle ha tagit bort.

Det svaga upplägget ser likadant ut

Här ligger den verkliga risken. Den handlar inte om pengar.

I ett svagt upplägg är morgongranskningen en stämpel. Testtäckningen är tunn, den som granskar hinner inte, volymen är för stor för att någon ska hinna förstå den. Då får man mycket kod snabbt, och den tekniska skulden byggs upp i samma takt.

Utifrån ser det identiskt ut med ett välskött upplägg. Samma rapportering, samma leveranstakt, samma tillfredsställda projektledare. Skillnaden syns först när något går sönder i produktion, och då har den byggts upp i månader.

En beställare kan omöjligt bedöma det från utsidan. Det är precis därför frågan ska ställas i förväg.

Fråga efter mekanismen, inte ambitionen

Alla svarar ja på om de granskar. Ingen svarar nej. Frågan måste därför gälla hur det går till.

Vad krävs för att något ska anses klart, och vem godkänner det? Kan något nå produktion utan att en namngiven person sagt ja? Vilken testtäckning finns i den nya kodbasen, och byggs den upp före eller under nattkörningarna? Hur många timmar per dag går åt till granskning?

Vid en migrering finns dessutom ett naturligt facit, nämligen det gamla mot det nya. Hur verifieras att de motsvarar varandra? Den jämförelsen är billig och deterministisk. Saknas den är det ett större problem än vad någon post kostar.

Ett bra svar låter som en process. Namngivna steg, ett namngivet ansvar, en spärr som inte går att gå runt.

Ett svagt svar låter som en försäkran. Att man såklart granskar allt, att kvalitet är viktigt för dem.

Skillnaden mellan de två svaren är inte artighet. Det är skillnaden mellan att ha byggt något och att tänka sig att man skulle göra det.

Se även: En kontroll som svarar olika är ingen kontroll (serie 56) och Frågorna du får om arton månader (serie 58).