Dine antagelser er forkerte!

Igennem et udviklingsprojekt laver man et væld af antagelser. Er man dygtig bliver en stor del af disse antagelser dokumenteret eller ligefrem indskrevet i testsuiten, men ofte laver man antagelser uden at overveje dem bevidst. En af mine første professionelle fejlantagleser af betydning var at adresser ikke indeholder kommaer (og at csv var et let format) - forestil jer min overraskelse da mine datafiler pludselig indeholdte et felt for meget fordi folk tillod sig at bo 'Denogdenvej 31, 1tv'...

Ofte viser antagelser sig først at være forkerte når man får rigtige brugere. Enten fordi brugere har en helt anden ide om hvordan et system skal bruges eller fordi den der "en ud af en million" race condition pludselig sker 5 gange om dagen (og iøvrigt viser sig at være selvforstærkende).

... I mit næste projekt lover jeg at jeg vil planlægge med at mine antagelser er forkerte. Det kræver at jeg for hver enkelt komponent sætter mig ned for at overveje prisen for at fikse et problem i komponenten. Når problemet så viser sig handler det ikke om hvis skyld det er. Det handler om at løse problemet billigst muligt.

Men hvad gør I når jeres antagelser viser sig forkerte en uge for sent?

Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Meldgård

Jeg er meget enig med dig i at antagelserne pr. definition er forkerte. Det betyder i min verden (mindst) 2 ting:
1) Dine estimater kan aldrig blive 100% og vil altid være et gæt. Lad være med at bruge alt for lang tid på dem, men se at komme i gang og brug noget tid på at reestimere undervejs. Jo tættere du kommer på målet jo mere præcise bliver dine restestimater.
2) Du skal ikke være bange for at refactorere din kode NÅR du har fundet ud af at det ikke virker godt nok. Den står lidt i kontrast til at du siger at det skal fixes så billigt som muligt. Det tror jeg kommer til at gå galt og resultere i alt or meget gaffa-tape.

  • 0
  • 0
Morten Andersen

For ethvert projekt jeg har kørende opretter jeg en workbook, en simpel .txt fil jeg har liggende direkte på skrivebordet. Hver eneste gang jeg er i tvivl om noget eller føler jeg gør en antagelse, opretter jeg en bullet heri f.eks. "Check at kunden er klar over at ...". Det er en slags TODO's bare mere overordnede ting frem for TODO's som er til en lille blok kode. Jeg kigger filen løbende igennem og adresserer dem løbende. Jeg sletter dem ikke men markerer dem blot som "brugt". Når jeg skriver dokumentationen kigger jeg også punkterne igennem, og det hjælper mig ofte til at huske at medtage nogle mere subtile ting.

Generelt betyder det dog ikke så meget for, kunderne læser sjældent hele dokumentationen, og hvis de gør er det ikke sikkert de forstår den eller kender implikationerne af de forskellige ting. Det vigtigste er at cleare de forskellige antagelser undervejs.

  • 1
  • 0
Erik Hedeby

Uden antagelser sker der intet! Skal vi altid finde al viden før vi gør noget som helst, når vi ingen steder! Antagelser skaber fremdriften! Men hvis vi ikke respekterer antagelserne som det de er, og bruger dem som facts, så fejler man helt.

Intet kan analyseres 100 %. Der er altid mulighed for at noget helt usanssynligt alligevel er muligt! Derfor skal man bruge antagelser til at skaffe fremdrift og respekten for undtagelser til at lave robuste løsninger, for kun sådan kan man lave hurtige løsninger, der ikke fejler ukontrolleret!

  • 0
  • 0
Michael Møller

eller din Forestillingsevne er for ringe :)..men der er kun en vej, ny kode. Hvis du er heldig er dit design så godt at det er til at ændre.
Synes strategy pattern har vist sig godt flere gange for mig. Men det kræver at du har en idé om at det "her er en potentiel antagelse om at der er noget der skal virke på en bestemt måde" ish.

  • 0
  • 0
Tim Christoffersen

Problemet er en forkert måde at lave sine projekter på.

En bedre metode er, bare at gå igang. Have et fast defineret mål, men uden at have planlagt alt for meget i processen på vej til målet.
Undervejs i processen kan man ændre i idéerne, og nøjes med at tilpasse små detaljer, så tingene stadig kører sammen. Det eneste man aldrig ændrer, er målet - det produkt man ønsker at nå frem til.

Efter et stykke tid, er man pludselig færdig. Står med et produkt der passer perfekt til de ønsker man havde fra starten, tilpasset de idéer og evt. forhindringer man har mødt på sin vej. Og stort set uden fejl.
De små fejl der evt. er tilbage, er forholdsvis nemme at finde og rette.

Sådan har jeg kodet, siden jeg begyndte. Jeg slår de fleste uddannede i hastighed og fejl-procent, samt applikationernes duelighed og runtime-hastighed.

"Man bliver ikke nødvendigvis klogere af at læse. Men man bliver helt sikkert dummere!"

  • 0
  • 3
Peter Makholm

Den står lidt i kontrast til at du siger at det skal fixes så billigt som muligt.

Jeg tror egentlig ikke at vi er så uenige. muligvis lægger vi forskellige ting i beregningen i hvad det koster at løse et problem, billig er ikke det samme som hurtig. Hvis man helt naivt kun ser på den tid det tager en udvikler gange det en udvikler koster i timen, så er jeg enig i at det leder til en gaffatape-løsning der let viser sig bekostelig i længden.

Lad os antage noget nær det værste eksempel: En fejlantagelse der viser sig at koste sporadisk korruption af kundedata. Det vil sige at det er ikke indlysnede for kunden at der er noget galt.

  • Prisen for at hive stikket indtil problemet er løst kan være et uopretteligt imagetab.
  • Prisen for at rekonstruere data og kontakte kunder øges for hver time problemet er uløst.
  • En given løsning koster noget udviklertid at implementere.
  • En given løsning kan tage forskellig tid at tvinge igennem.
  • En given løsning kan have en pris at vedligeholde.
  • En given løsning kan lukke dørene for senere at implementere andre løsninger.

Hvis punkt nummer 2 er betragtelig kan det betale sig at optimere for kort gennemførelsestid - selv hvis det betyder at det bliver væsentligt mere problematisk at senere løse problemet på en måde der er billig at vedligeholde.

  • 0
  • 0
Peter Makholm

Problemet er en forkert måde at lave sine projekter på.


Jeg er stor tilhænger af iterativ udvikling med en kort reaktionstid. Specielt velegnet er det hvis det endelige mål ikke er helt fast defineret, men for eksempel afhængig af en udefineret brugerbase som man ikke kan gennemtvinge et bestemt brugsmønster overfor.

Desvære er det ikke altid muligt. Det kan både være af forretningsmæssige grunde da det forringer wow-effekten eller fordi man laver en reimplementering af et system og en glidende overgang er bekostelig.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize