SuperSchnell.net

Estimering og planlægning episode 3

Wed, 18 Mar 2026 17:05:04 +0100

Serien

Episode 1 – Den med forudsætningerne
Episode 2 – Den med opsplitningen
Episode 3 – Den med den grove nedbrydning (du er her)

Strategisk estimering. Vores projekt har nu rammerne, vi har en prioriteret liste af opgaver - hvor forretningen har valgt hvilke funktionaliteter, der giver mest forretningsmæssig værdi. Nu skal det kobles med hvad hver del koster at lave. En dygtig udvikler har prøvet lidt af hvert - de ved hvor diverse dyr er begravet rundt omkring i systemlandskabet, og de bør have en god fornemmelse af teamet. Læg mærke til at jeg intet skrev om lead-/senior- og andre titler for udvikleren. Ofte er det faktisk en fordel, at have en blanding af erfarne udviklere og forholdsvis nye udviklere med i den her proces. En virkelig dårlig ide er at samle alle de største egoer i et lokale, hvor der skal gives forholdsvis hurtige estimater.

Kompleksitet

Vi skal bruge estimater, der siger noget om a) kompleksiteten i den enkelte opgave og b) usikkerheden. Nogen bruger T-shirt størrelser (tænk Large, Medium og Small) andre bruger udvikleruger – detaljerne er ligegyldige, tidsforbruget er ligegyldigt (på nuværende tidspunkt). De estimateter vi laver her, har en række andre formål – de er relative til hinanden. Det første og vigtigste formål er at danne et overblik over om det overhovedet er et godt projekt. Hvis alt er mere komplekst og tungt end forventet, så er en valid beslutning her at nedlægge projektet. Alternativt kan projektet skæres til – det skal virke sandsynligt at de tilbageværende opgaver kan løses inden for tidsrammen.

Næste formål med den her grovestimering er at finde ud af om udviklergruppen indeholder alle de kompetencer vi skal bruge – eller om vi skal bruge nogle ekstra resourcer. Dernæst bør den her estimering resultere i at prioriteringen af opgaverne genovervejes. En afvejning mellem hvor dyr (målt i kompleksitet) den enkelte funktionalitet er i forhold til forretningsværdien. Igen, jo hurtigere vi kan vise fremdrift i et projekt – jo større engagement og positivitet vil der være om projektet. Hvis vi med kun en moderat indsats kan levere værdifuld funktionalitet i uge 3 af projektet? Så har vi fået en flyvende start.

Hvad der sker her, bliver her

En absolut dødssynd er at bruge de her estimater til senere at følge op på om udviklergruppen så nåede den enkelte feature på den tid, de ’lovede’. Det er gift for næste projekt, fordi den enkelte udvikler så vil begynde at gange alle estimater med to. Eller tre. Al erfaring siger, at vi gætter vildt forkert i det her stadie – jo flere features, jo mere forkert gætter vi. Til gengæld gætter vi forkert i begge retninger, pointen er, at det her er en del af den lærende proces. Jo flere projekter vi laver, jo bedre en fornemmelse vil vi få for de hurdler, der er i organisationen.

Det vigtige her er at det er intuitionsbaserede estimater (også kendt som WAG’s – wild-ass guesses) – ingen detaljer er tilladt. Hvis det hjælper, så brug et spænd til at beskrive kompleksiteten. 2-12 udvikleruger er et validt gæt – det signalerer også at det er en opgave, vi skal være særligt opmærksom på, når vi kommer tættere på udførelsen. Hvis spændet er 20-250? Så skal opgaven brydes mere ned; den er for uhåndterlig og for usikker til at en god projektleder vil røre den med en ildtang.. i en asbestdragt.. på fyrre meters afstand..

Konklusion

Denne her indledende fægteduel mellem udviklingen og forretningen er i høj grad en forventningsafstemning. Er det business-as-usual, nu i rød… eller er det alle-mand-til-pumperne-det-kommer-til-at-gøre-ondt, vi taler om. Den forståelse mellem afdelingerne er guld værd – ikke bare til det her projekt men til den endeløse række, der ligger i fremtiden.

Estimering og planlægning episode 2

Sat, 03 Jan 2026 08:48:30 +0100

Serien

Episode 1 – Den med forudsætningerne
Episode 2 – Den med opsplitningen (du er her)
Episode 3 – Den med den grove nedbrydning

Lad os nu sige, at alle de perfekte forhold er tilstede for projektet – ledelsen er med, resourcerne er tilstede og der er et solidt forankret mål for det hele (Alt det i episode 1). Nu er det tid at få projektet splittet op. Igen, projektmodellen er ikke rigtig vigtig på det her stadie – det er mere et spørgsmål om at danne rammerne.

Detaljer er fjenden

På nuværende tidspunkt er vi interesseret i hvad der skal bygges, ikke hvordan. Hvilket web framework, der skal anvendes; om det skal være en microservice arkitektur; hvor det skal hostes. Alt sammen i bedste fald distraktion på nuværende tidspunkt. Nej, vi skal have klarlagt præcis hvilke forretningsbehov projektet skal løse – og, mindst ligeså vigtigt, hvilke procedurer vil vi gerne ændre. Der skal være noget ‘godt’ for enden af regnbuen, der skal være noget mærkbart, der er ‘bedre’ i forretningen bagefter. Hvis det er et kundevendt projekt, skal der være ’noget for dem’. Det virker banalt at skrive det, men det går overraskende ofte galt. Enten glemmer man de ændringer, der skulle til i organisationen for at understøtte det nye software – eller man glemmer at spørge brugerne, hvad de egentlig har brug for.

Prioritering, prioritering, prioritering

Efterhånden som projektet bliver nedbrudt i hvilke arbejdsgange, processer og organisationsændringer, der er påvirket – så skal det prioriteres, hårdt. Der kan kun være en prioritet 1. “Jamen, det hele er vigtigt!” (jeg kan høre præcis den indkøbschef for mit indre øre) Og ja, det hele er vigtigt, ellers ville det ikke være med i projektet – vi beskæftiger os ikke med ikke-vigtige ting. Men. Det er ikke lige vigtigt. Tænk det som “Hvis det her ikke er der, er projektet dødfødt”-vigtighedsgrader. Altså, design projektet efter, at hvis vi når de 80% højst prioriterede ændringer, så er det en success (læs: det giver værdi for forretningen). 80-150% er bonus. (Og ja, jeg har været med i projekter, hvor vi nåede alle prioriteterne og fik et par boblere med)

Rækkefølgen – Byg det vigtigste først

Med mindre. Der vil altid være afhængigheder mellem de prioriterede opgaver – og så er der den eviggyldige sandhed: Det psykologiske betyder 71,9% [1] af succes-raten for projekter. Et feedback-loop så tidligt som muligt bør prioriteres. Det har mindst to formål: Tidlig identificering af logiske fejlslutninger og følelsen af fremskridt. Igen, stadig uafhængigt af om vi kører med vandfald eller agilt. Men ellers er hovedreglen – det vigtigste først – og byg hver del færdig [2]. Og ja, det inkluderer ting som tilgængelighed og lokalisering. Det er a) svært og b) tidskrævende at bygge ind som en eftertanke. I agile kredse kalder man det DoD (Definition of Done) – hvornår kan man betragte dette område for færdigt. Testere kalder det Acceptance Tests. Der skal være 100p enighed om det fra alle, der har bacon på linjen.

Konklusion

Den her fase af projektet er super-kritisk. Den skal få alle, der er med i projektet på samme side i manuskriptet i forhold til Hvorfor. Hvor passer det her ind i forretningen; hvem hjælper vi; hvad ændrer vi – find selv på flere hv-ord. Alt for ofte har jeg set diskussioner, der er kørt ud af tangenter om hvorvidt det ene framework var bedre end et andet.

[1] Bestemt ud fra upartisk terningerul af min datter.
[2] Ikke færdig-færdig – funktion over form (læs: Vent med polering)

Estimering og planlægning, episode 1

Fri, 02 Jan 2026 05:58:18 +0100

Serien

Episode 1 – Den med forudsætningerne (du er her)
Episode 2 – Den med opsplitningen
Episode 3 – Den med den grove nedbrydning

Der er skrevet tykke bøger om, hvordan software bør planlægges og bygges. Og der er kurser. Og uddannelser med tilhørende certificeringer. Og konsulenter. Alligevel går det stort set altid galt (i en eller anden grad) af mange forskellige årsager. Jeg tror efterhånden, jeg har prøvet alle modellerne – fra ‘Plan, pssh – vi ved jo godt hvad vi skal lave’ over diverse agile modeller til Vandfald TTM (I nogle spektakulære tilfælde var det at lave projektplanen i sig selv et projekt, der krævede sin egen model…) og min erfaring er at den valgte model ikke har haft afgørende indflydelse på om projektet er lykkedes eller ej. Det her indlæg bliver en del af en længere serie, for jeg har holdninger (tm).

Risikofaktorerne

Størrelse – dræberen af alle projekt(plan)er. Der er masser af andre risici, men de blegner alle i forhold til størrelsen af projektet. Kompleksiteten og usikkerheden af et hvilket som helst projekt stiger ikke linært med størrelsen af projektet – de stiger eksponentielt. Forskellen mellem at skulle bygge software til at løse en specifik lille del af forretningen og så at skulle bygge software som skal håndtere 100 små sspecifikke dele af forretningen, som har indbyrdes afhængigheder… Bare at regne ud hvilke dele, der skal bygges før andre, kan hurtigt blive et projekt i projektet.

Det grundlæggende problem er egentlig ikke det at bygge software – som enhver udvikler vil fortælle dig, så er det ligeså nemt at følge en kravspecifikation som det er at gå på vandet – hvis de bare er frosset, skal det nok gå. Problemet er at software skal løse et forretningsproblem i virkeligheden – og virkeligheden er kompleks og ændrer sig over tid.

Så er der ledelsen af projektet og her mener jeg ikke projektlederen, men de personer, der har besluttet at projektet skal startes. Hvis der ikke er defineret et klart mål og en benhård prioritering fra start, kommer det til at være en klods om benet i hele projektets levetid.

Den sidste store risikofaktor er organiseringen af projektgruppen. Alle projekter har brug for involvering af nøglepersoner i processen – ligegyldigt om de er en fast del af projektgruppen eller der er afsat tid til at de kan agere konsulenter. Der er en række formål med det – dels at de får ejerskab, dels at der sikres mod misforståelser (læs: kvalitetssikring). Hvis et projekt ikke er solidt forankret, er der stor risiko for at slutproduktet aldrig opnår det potentiale, der var hele grunden til udførelsen.

Det er altid chefens skyld

Provokerende, men ikke desto mindre rigtigt. Chefers fornemste opgave er at sikre at deres medarbejdere lykkes med deres opgaver, herunder projekter – som en umiddelbar konsekvens: De skal skabe rammerne, som muliggør succes. Igen, vi taler ikke om projektledelsen – vi snakker om den ‘rigtige’ ledelse. Ligegyldig hvor god en udviklergruppe og projektledelse, du har – hvis ledelsen ikke er a) direkte involveret og b) bakker 100p op om projektet så er projektet virkelig udfordret. Jeg siger ikke, det er umuligt – jeg siger blot at det er ikke er lykkes endnu at opdrætte fisk i sand.

Konklusion

Selv hvis man gør alt det rigtige – små projekter, massiv ledelsesinvolvering og allokering af tilstrækkelige resourcer, er det ikke garanti for succes, men! der er en selvstændig pointe i, at selv hvis vi fejler – så er vi blevet klogere på forretningen og tabet af resourcer er ikke truende for forretningens eksistens. Jeg er abonnement på ideen om den lærende organisation og hvis vi gør det legitimt at fejle, så lærer vi hurtigere og er bedre rustet til næste projekt. For en ting er sikkert, den dag en forretning stopper med projekter er samtidig dagen, hvor der kun er afvikling tilbage.

Valg af projektmodel er en spændende nok diskussion, men hvis ovenstående ikke er på plads, er det som at flytte på skraldespandene i en brændende bygning – en god workout, men samtidig skønne, spildte kræfter.

GenAI og andre vederstyggeligheder

Mon, 29 Dec 2025 07:02:45 +0100

Jeg kan med nogen stolthed sige, at jeg ikke har brugt ChatGPT, Dall-E og andre (de)generative AI-modeller – og kommer ikke til det. I min verden er der to typer af problemer med teknologien: De etisk/moralske og så de tekniske.

Etik og moral

De firmaer som står bag de her værktøjer respekterer ingen regler og opfører sig som græshopper i deres uendelige søgen efter mere materiale – og de ved det godt selv. Mange open-source projekter oplever at 95+% af deres trafik kommer fra scrapere. De omgår alle de gængse bot-værn (robots.txt osv.) – senest via browser(plugins), så når en vilkårlig bruger lander på en hjemmeside, sender den lige en kopi af det viste til gæt-en-anløben-type.

Licenser, ophavsret og andre intellektuelle rettigheder bliver rutinemæssigt ignoreret. Med et økonomisk begreb eksternaliserer de omkostningerne til organisationer og privatpersoner, der aldrig har accepteret vilkårene og ej heller får del i de ‘værdier’, der skabes.

Så er der resourceforbruget i datacentrene. Det er voldsomme mængder af strøm, vand og hardware, der bliver kylet efter de her modeller – at det på ingen måde stemmer overens med den (ret begrænsede) nytte, der kommer ud af dem. Vi snakker mængder, hvor de seriøst overvejer at bruge jetmotorer til at lave nok strøm og få naboer til at begrænse deres bade.

Teknikken

Modellerne er gigantiske statistiske modeller – meget forsimpelt teknikken du oplever, når du skriver en SMS og telefonen foreslår næste ord. Ideen er, at tage så mange skrevne kilder som muligt, splitte dem ned i mindste bestanddele og så ‘forudsige’ et svar ved at tage de mest sandsynlige ord ud fra en lang række parametre. Der er ingen smålig skelen til om kildeteksten kommer fra Reddit, Hestenettet eller et tilfældigt indlæg på en kodesnedkers blog udover ‘vægte’ – mao. så vægter en shitpost på Reddit langt højere end et indlæg på en tilfældig blog.

Vigtigere, er der ingen skelnen i forhold til korrekthed. Dvs. at hvis man bruger kodeværktøjer baseret på GenAI, så vil de foreslå kode, der a) ikke har korrekt syntax, b) er uddateret og/eller c) ikke passer med den eksisterende kode – og der vil blive foreslået kode, som er overrepræsenteret i kildedata.

Den sidste pointe kræver en forklaring. Jeg har arbejdet med kode i omkring 25 år. Jeg har lært rigtig meget i løbet af den tid - min bedste kode er den jeg laver i dag. Når jeg kigger på min egen kode, der er mere end tre måneder gammel… så er der ikke plads i mine sko til mine tæer. Så hvis vi tager mine samlede værker, så er 99% af det i kategorier mellem ‘ringe’ og ‘decideret forkerte’ (25 år = 100 kvartaler, kun det sidste kvartal vil jeg vise frem med stolthed). Og hvis der er noget, internettet har bevist over tid, så er det hvor meget alle mennesker tager fejl langt det meste af tiden.

Sidst, men bestemt ikke mindst – så er jeg system-menneske. Jeg vægter forudsigelighed og stabilitet langt højere end hastighed. ChatGPT er baseret på et interface, hvor man skal gætte på syntax. Over tid bliver man så bedre til at gætte ud fra arbitrære ~~myter~~ regler, som skifter over tid (når der kommer nye versioner af systemet). Selv hvis jeg gætter rigtigt, vil jeg ikke få samme resultat som sidst, hvilket totalt diskvalificerer det som et værktøj for mig.

Konklusion

Ovenstående er kun et udsnit af problemerne ved GenAI – derudover er der de kognitive påvirkninger. Når Microsoft selv har forsket sig frem til, at udviklerne a) overvurderer gevinsten (som tenderer til at være negativ) og b) bliver dårligere over tid, så bliver det et nej-tak, herfra.

Der findes helt sikkert use-cases for dem – som en marginalt bedre Google Translate, når du står i et fremmed land. Eller som fallback, når udviklerne for n’te gang ikke har indtænkt tilgængelighed i deres brugerflader. Jeg synes bare slet, slet ikke det står mål med omkostningerne – både i forhold til klima, sårbare menneskers afhængighed og presset på open source udviklere, forfattere og kunstnere. De resourcer kunne vi med fordel have anvendt til at løse de problemer, istedet.

En kodesnedkers bekendelser

Sun, 28 Dec 2025 16:40:10 +0100

Kodning er for mig noget, der kom snigende. Tilbage i forrige årtusind var jeg knapt klar over, at formler i Lotus 1-2-3 var kodning. Det var bare en genvej til ikke at skulle opdatere totaler via viskelæder og mere grafit.

Da jeg byggede et system i Access til at lave overslag på køleanlæg, var det fordi vores Excelark var i atten versioner og der var vidt forskellige priser i dem. Et givent tilbuds totale pris afhang af, hvilket tidligere tilbud sælgeren tog udgangspunkt i. Til min gru bliver det system stadig brugt.

Så var der økonomisystemerne, hvor man kunne tilpasse logikken, så manuelle processer kunne strømlines og effektiviseres. Det foregik i horrible afarter af BASIC-lignende syntax og bygget ovenpå databaser, der var glorificerede tekstfiler med indeks i andre tekstfiler.

Det var først, da jeg blev hyret til at bygge Xena i 2010, at jeg reelt begyndte at kalde mig programmør og systemudvikler. Dengang var det helt almindeligt ikke at have en formel uddannelse indenfor faget - vi var kodesnedkere, praktikere.

Jovist, vi var nogle stykker, der tog det alvorligt at læse op på alt det, vi ikke vidste – design patterns, optimering af SQL osv. – men vi var et fåtal. Fokus var at få noget ud i verden, der løste et problem eller optimerede en proces. Vedligehold var i bedste fald en eftertanke.

Mange ord for at forklare formålet med bloggen her - al min erfaring omkring spændingsfeltet mellem forretning og IT - og så alle mine hot-takes. Der er masser af mere tekniske blogs derude af folk, der er mig overlegne. Folk som Ayende der lærte mig rigtig meget om ORM og mere specifikt NHibernate.