En af de udfordringer, vi ofte møder, når vi arbejder med software- og produktudvikling, er estimering af samme. Der opstår i udviklingsforløbet, helt forståeligt, spørgsmål omkring, hvorfor vi ikke med større sandsynlighed kan svare på, hvor lang tid en opgave tager at udføre.
Programmering er komplekse abstraktioner over de muligheder, en computer stiller til rådighed, koblet med potentielt komplekse domæner, som skal formes af disse mulige abstraktioner.
I bunden af 'stakken', omkring hvordan en computer fungerer, og for at forstå bare en lille smule af, hvor meget abstraktion der ligger ovenpå, kan du betragte en CPU - hjertet i det, vi kalder en computer - som værende det mest standardiserede i forbindelse med softwareudvikling.
Jo mere vi er sikre på, at noget bare virker, des mindre skal vi koncentrere os om det. Teknikken, altså det at programmere, er sjældent udfordringen, så længe programmøren tidligere har erfaring med nøjagtigt samme udfordring. Nøjagtigheden skal du ikke tage fejl af.
Der er f.eks. forskel på at implementere den samme regnemaskine i to forskellige kodebaser. Der er forskel på, om programmør A eller programmør B implementerer regnemaskinen - de tænker nok ikke helt ens.
Hvis du vil have to programmører til at udforme ens arbejde, skal du først selv skrive programmet, som du ønsker det, og dernæst bede dem om at kopiere det 1:1. Så er det ikke længere programmering, men snarere som at stå ved et samlebånd.
Det er blot et simpelt eksempel, men ikke desto mindre helt validt.
Vi kan altså med ovenstående udlede, at resultatet af et udviklingsforløb altid vil være forskelligt, såfremt forskellige individer løser det. Og vi kan også udlede, at resultatet hos en enkelt programmør varierer på baggrund af de givne rammer - f.eks. hvis en regnemaskine skal implementeres i to forskellige kodebaser.
Der findes naturligvis standarder omkring teknikken. Og det gør der egentlig også i forbindelse med velkendte domæner, f.eks. en bankkonto. Men det er, når vi begynder at udvide disse domæner, at tingene kan blive mere udfordrende.
Det ukendte er altid svært, når vi udvikler software. Hvad du ikke kender, kan du ikke med relativ sikkerhed estimere korrekt. Og tilføj dertil, som en ekstra dimension, mennesker, som skal arbejde sammen. Så begynder vi at opleve en forøget kompleksitet.
Før vi overhovedet kan komme med plausible bud på estimater, skal vi forstå, hvad kravene er til dette. Nogle vælger at skrive disse krav ned - det anbefaler jeg stærkt, at man gør. Man kan ikke, er min overbevisning, lave noget fornuftigt uden at have forstået, hvad målet er.
Omvendt er det at lave en fuld specifikation ofte ikke fordelagtigt, simpelthen fordi al viden ikke er til stede på forhånd, og ofte ændrer den viden sig, når resultatet bliver håndgribeligt - altså når vi kan se og mærke noget.
Det gør det derfor endnu sværere at estimere noget som en færdig ting på forhånd. Men hvis målet har været nemt at ramme, er det ofte fordi målet har været småt.
Alt software er forskelligt, også selvom det synes at opføre sig ens på overfladen. Det er fordi abstraktionerne er gemt væk (netop derfor det er abstraktioner), så vi ikke ser, hvordan det er skruet sammen nedenunder. Men det ligner jo hinanden til forveksling, om du logger ind på den ene eller anden netbank f.eks.
Ud over det er mulighederne med disse abstraktioner (som dybest set starter over CPU'en og går opad) så forskellige, at programmørerne har uanede muligheder for at være kreative og udforme sig efter bedste evner.
Men programmering kan ikke andet, fordi det er domænet, som bestemmer kompleksiteten af, hvor langt teknikken kan strække sig, og derfor bliver programmøren eller gruppen kun efterladt med muligheden for at agere kreativt.
Der findes ikke nogen løsninger, som kan hindre dette faktum omkring kreativitet, andet end at gå til arbejdet med en holdning om, at det vi skal nu, er svært, fordi vi potentielt ikke afgrænser muligheden for at agere kreativt.
Når jeg skal forklare, hvordan forskellen på udeblivelsen af kreativitet (som dybest set er en subjektiv holdning) til forskel for, hvordan software bliver til og estimeres, så bruger jeg nogle gange en analogi omkring, hvordan en forbrændingsmotor fungerer.
Men det er en uretfærdig sammenligning, fordi i software er kreativiteten en nødvendighed. Der findes meget sjældent et domæne, der menneskeligt er implementeret fuldstændig identisk, hvorimod forbrændingsmotoren altid består og drives af de samme dele og som - måske heldigvis - ikke drives af mennesker.
Med forbrændingsmotoren er vi kommet til en konklusion. Vi ved, hvordan den virker hver gang. Og derfor er den et nemmere udgangspunkt at estimere ud fra, når den f.eks. er gået i stykker (hvis det altså ikke er software, der f.eks. styrer indsprøjtningen).
Estimater i software er altså svære, fordi de ofte skal implementeres på baggrund af komplekse domæner, i samarbejde med andre mennesker og på baggrund af kreativ individuel indblanding og eksekvering