Debugging den tabte generation
Dagens debug-summit var en utrolig positiv oplevelse for mig.
Det er meget tydeligt, i hvertfald i det selskab, at der sker en hastig professionalisering af IT branchen.
Det har jeg savnet i ca. 20 år.
På sin vis vil jeg påstå at dagens møde kunne være holdt præcist magen til i 1993, dengang, inden IT branchen exploderede med en faktor 1000, talte man også om at professionalisere programudviklingen, at undgå debugging ved at forbedre koden på forhånd osv. osv.
Intet sted var det tydeligere end med foredraget om debugging af Linux kernen, der om noget software har repræsenteret dot-com generationen i trods-alderen.
Som en stor fan af den naturvidenskabelige metode er det naturligvis rart at se at de genopfinder præcis de samme løsninger som alle andre har fundet år, eller i visse tilfælde årtier tidligere, men efterhånden burde nogen i den lejr begynde at lugte lunten og stoppe "Kan Selv!" flippet.
I virkeligheden var der ikke ret meget nyt idag.
Den ene teknologi vi så idag der ikke var mainstream i 1993, var grafiske IDE'er.
De fandtes dengang, på Rational R1000 Ada maskiner, men mainstream var de bestemt ikke.
Det er de idag, men med al respekt for foredragsholderne, så var de grafiske IDE'er ikke stjernerne idag.
Jeg skal ikke gøre mig klog på om man faktisk kan debugger Java på anden vis, men IDE som fremtidens debugging-mirakel køber jeg ikke.
En anden ting jeg bed mærke i idag, var at Microsoft er faldet i samme hul som IBM's mainframes: Et mareridt af dump-typer, dump-fortolkere der skal gøre bunkerne af rå bits nemmere at læse, men som ofte kun hjælper marginalt.
At Microsoft og IBM begge er havnet i denne blindgyde har samme underliggende årsag: Det koster at være default platformen hvor selv de ringeste programmører kan få job.
Forestil jer, at hver programmør på Windowsplatformen bare en gang i sit liv finder hvad de tror er en OS fejl og sender en dumpfil til Microsoft.
De tager næsten alle fejl, men hos Microsoft vælter dumpfilerne ind og man har brug for værktøjer der gør det nemmere at returnere "blame-allocation" serven.
For enden af det mareridt ligger "dumpfils-analysers" med en komplex plug-in-arkitektur således at hvert stykke buggy middelware kan plugge sig selv ind og lave lort i debug-processen også. Inden længe skal man til at analysere dumpfiler fra dump-fil analysator programmet...
Nej, dump-filer er helt klart ikke vejen frem.
Konklusionen idag, idet omfang der var en, er at debugging handler rigtig meget om erfaring, ikke mindst den erfaring at debugging overhovedet ikke er sjovt og at det derfor bedre kan betale sig at bruge 10-30% af tiden up front på program-kvalitet, frem for 120% senere på debugging.
Det er et budskab mange virksomhedsledere og politikere har brug for at få banket ind i hovedet med al nødvendig magt.
Digital Tinglysning skandalen handlede f.eks i bund og grund om at man "ikke havde tid og råd til alle de tests" -- med helt forudsigelige resultater.
Den påståede "ældre-visere" korrelationen er bestemt relevant, hvilket bringer mig til dagens to første og på sin vis vigtigste foredrag: Hvordan håndterer vores IT uddannelser debugging.
Forskellen på Ballerup og Herning var ikke større end i så mange andre emner: I Jylland får man tingene til at virke, på den ene eller den anden måde, nær København er der ingen ting der kan lade sig gøre uden at der går politik i det. Det lyder utroligt bekendt.
Min personlige mistanke har altid været at debugging forudsætter at man faktisk forstår hvad der sker mens computeren kører.
Forstår man ikke run-time miljøet, kan man ikke formulere gode og brugbare hypoteser for hvad der kan være galt og dermed ikke opstille forsøg der skal afgøre deres sandhedsværdi.
Alle kender den tendens mennesker til at pege på ting man ikke forstår som ondets rod: Det er en compiler-fejl, det er en fejl i garbage-collect, det er databasen der ikke kan finde ud af at bruge sine index osv.
Selvfølgelig forstår man i et eller andet omfang hvad der sker i Python, JVM eller på toppen af en zMachines elfenbenstårn, men man forstår det ikke rigtigt for der er tusinder stumper kode at forstå, fra garbage-collect til CICS og VTAM.
Selve OO-conceptet er formodentlig problematisk, rent undervisningsmæssigt, for der er ikke noget OO over hvad maskinen faktisk gør: OO er et abstraktionslag der skubbes ind imellem sproget vi programmere i og maskinen vi kører på og først når man forstår hvorledes den abstraktion er implementeret, kan man gennemskue hvorledes man debugger på tværs af den.
Jeg de har fat i den rigtige ende i Herning: En lille ARM processor med C kode er en sandkasse man kan overskue og forstå: Timingproblemerne skyldes ikke en dårlig video-driver, den blendede datafil er ikke et resultat af anti-virus programmet: Der er noget hardware, der er noget kode I selv har skrevet. Gæt selv hvor fejlen skal findes. Det er en pædagogisk brugbar situation. Det var ihverfald sådan jeg lærte debugging.
Debugging er ikke bare værktøjer og metode, det er også et arbejde.
Flere af indlægsholderne var inde på at de rigtig svære debug-opgaver havnede samme sted hvergang: Hos en lille flok garvede medarbejdere der bare kan det pis.
I et ikke navngivet firma havde man taget konsekvensen og samlet en håndfuld af dem og givet dem ansvaret og det havde givet pote.
Det fremgik dog mellem linierne, at det ikke var noget de gjorde til en karierre, forstået på den måde at efter et halvt års tid, var det på tide at skifte ud i holdet.
Men spørgsmålet jeg sad tilbage med, var om det i virkeligheden var debugging den gruppe foretog sig og hvis det var, om det var af koden eller udviklingsprocessen ?
Havde man i virkeligheden udstyret dem med et arkitektonisk mandat via bagdøren, så de kunne få rettet de værste stukturelle problemer, få elimineret de arkitektoniske klumsetheder der førte til at der kom så mange fejl til at begynde med ?
Jeg kan ihvertfald sagens forestille mig fire erfarne medarbejdere, behørigt mandateret, ville stikke hovederne sammen og komme frem til at "Nu kan vi endelig slippe af med ${midlertidig_klamphuggeri} modulet."
Kunne man have opnået samme effekt ved at have udpeget en arkitekt til at begynde med ?
Desværre kunne de to ledere der fremlagde denne historie ikke byde ind med den anden halvdel af vinklen: Hvad lærte ledelsen om debugging ? og debuggings plads og allokering i projektforløbet ? Det er ellers også en rigtig øm tå.
Mit eget indlæg endte som en slags opsummering på dagen, for stort set hver evig eneste pointe jeg havde planlagt, var blevet nævnt eller brugt af andre foredrag i dagens løb:
Kod defensivt, "smart" kode er for svært at debugge.
Brug kode-analyse værktøjer, fra -Wall til Flexelint og Valgrind.
Assert() at du ved hvad der foregår, det virker både som dokumentation og fejl-check.
Find og reager på fejlen så tidligt som muligt, både i programmet og i udviklingsafdelingen.
Når fejlen sker, få programmet til at spytte brugbar high-level debug information ud, frem for bjerge af core-dumps.
Test koden, de fejl der ikke er der, tager ingen tid at debugge.
En stor tak til Peter og Kenneth for initiativet, til Mediehuset Ingeniøren/Version2 for lokalerne og Danske Commodities for at sponsere.
phk
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
