Hvad er dit problem ?

Man taler tit om, at forskellen på en meget effektiv udvikler og hans diametrale modsætning er op til en faktor 10.

Jeg tror det er alt for lavt sat...

Men lad os tage et eksempel fra virkeligheden:
Problemløsning og fejlsøgning ' hvorfor er der så markant forskel på, hvor gode udviklere er til dette '

Her er virkelig en situation hvor den gode udvikler og den knapt så gode adskiller sig fra hinanden, nemlig når der opstår et problem i et system - dvs. at en elskelig lille fyr ved navn bug kravler ind i systemet og skaber kaos.

Så hvad gik der galt ' Og hvordan finder vi frem til årsagen '

Den knapt så gode udvikler skyder måske først skylden på styresystemet.
Så prøver han at genstarte sine pc en enkelt gang eller to.
Dernæst lægger han måske ganske korrekt et debug statement ind, så han kan få en fornemmelse af, hvad der er galt.

Men så begår han den ultimative dødssyn....
Han retter ***to (2!!!) ***ting på én gang og tester så igen...

Sådan fortsætter dagen. Utallige timer og debug statements senere er fejlen måske væk...

Svaret på alting...

Er som bekendt 42, eller binært 101010...
(Jeg har hørt om et stort IT-projekt der har 10/10/10 som sin deadline...spooky ! )

Svaret på perfekt problemløsning er noget i retningen af:

  • gå metodisk til værks, start evt. med en mindmap så du har overblik over afhængigheder i dit system
  • ret kun ***én (1!!!)*** ting ad gangen !
  • lad være med at glo på skærmen i 3 timer for at spotte en fejl, gå i stedet en tur eller fortæl andre om dit problem

Det lyder enkelt, men det handler naturligvis også om, at have erfaringen til at spotte symptomer og derudaf aflede årsager hertil.

Kan man købe for 20 kr erfaring her ?

Hvilket bringer mig til en personlig kæphest.

Ja, det handler om erfaring og netop det kan man jo ikke uddanne eller købe sig til.

Erfaring kommer igennem øvelser, og det er nok et grundlæggende problem for vores branche.

Vi øver os ikke nok !!!

Folk som Richard Gabriel argumenterer også for, at det at skrive, fejlsøge og modificere software er noget vores uddannelsessystem og arbejdsgivere forsømmer:

We never had software writing education, so most software ... sucks

Se evt. denne præsentation for et bud på, hvordan vi i vores branche kan tage ved lære af andre fag...

Eller som en god bekendt sagde til mig forleden:
Hvorfor er det, at vi kun øver os i rigtige projekter ? Det vil jo svare til at sende soldater i krig uden øvelse....

Men hvad pokker, det er jo kun kundernes penge og risiko det går ud over....

Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jonas Kongslund

I forbindelse med fejlretning har jeg af bitter erfaring lært følgende: genskab altid selv fejlen i dit lokale udviklingsmiljø, inden du begynder at rette den.

Det er en triviel regel og nogle gange fristende at springe over i de situationer, hvor man på forhånd tror man ved, hvor bæstet ligger begravet. Nogle gange går det godt og andre gange har man lige pludselig spildt adskillige timer fordi ens initielle antagelser var forkerte. Det sker typisk med de fejl, som er lette at rette, men svære at lokalisere.

En af mine kollegaer, Claus, formulerede på et tidspunkt det han selv kaldte for Claus' 1. lov: tiden det tager at finde en fejl er omvendt proportional med tiden det tager at rette den.

Gang på gang bliver jeg bekræftet i rigtigheden af denne empiriske lov.

Poul-Henning Kamp Blogger

Jeg ville da elske at kunne genskabe alle de fejl folk sender til mig.

F.eks den hvor email'en startede med: "If you have a cluster of more than 1000 FreeBSD machines and..."

I praksis handler fejlsøgning om at vide hvad programmet skal gøre og hvordan det skal gøre det og så derfra gennemskue udfra den fejlagtige opførsel hvad eller hvor det gik skævt.

Alle mulige metoder, teorier og grafiske dimser kan ikke opveje et grundigt kendskab til programmet der fejler.

Poul-Henning

Helge Svendsen

Hejsa,

Jeg er meget tilbøjelig til at give PHK ret.

9 ud af 10 fejl er fejl mellem miljøer (UDV/TEST/PROD), og næsten altid i de data, der er i de forskellige miljøer.

Det er nogle gange meget svært at genskabe forudsætningerne for en fejl.

Når der er en reel programatisk fejl, så synes jeg altid de er ret nemme at finde vha. ganske alm. debug step through.

Jonas Kongslund

Udmærket eksempel Poul. Ja, der kan selvfølgelig være situationer, hvor man ikke har mulighed for at have samme setup som det miljø, hvor der optræder en fejl. Jeg tænker på mit tip som en tommelfingerregel - ikke en regel - der bruges i de situationer, hvor det giver mening.
Jeg er i øvrigt ikke uenig i at man er hjulpet godt på vej med et grundigt kendskab til programmet, der fejler.

Stefan Kreisberg

IMHO er det relativt let at spotte ordinære programmeringsfejl, men måske forstår jeg ikke omfanget at en "fejl" i denne her kontekst? De virkeligt sværre fejl, er dem der opstår som en følge af en ufordset brug af et udviklet system - altså når man som programmør mangler overblik og indsigt i hvorledes systemet tænkes benyttet. I min verden er ordinære fejl og evnen til at finde disse, i høj graf afhængig af erfaring. Det er faktisk mere vigtigt at have en god erfaring, og dermed næse for at finde fejl, end om det er een eller otte man retter på samme tid. Hvis man retter mere end een ting uden at være klar over om det man retter er det rigtige, er man efter mit bedste skøn meget langt væk fra at være på rette spor. Men det er måske blot at sige det samme på en anden facon?

:-)

Log ind eller Opret konto for at kommentere