Lang verwachte bevalling op kantoor

Ik werk op kantoor al meer dan een half jaar aan Spidi. De klant gebruikte nog steeds de oude versie, terwijl de nieuwe versie al eind 2006 door onze voorgangers opgeleverd was. Daar zat een heleboel goed werk in, maar ook een heleboel niet goed. Die versie was dus niet geaccepteerd door de klant. Het heeft mij meer dan een half jaar gekost om alle bugs, incomplete functionaliteit en andere gekkigheden te corrigeren.

Eindelijk dan, afgelopen dinsdag, hebben we de nieuwe versie live gezet. Ik zat tot negen uur op de ECT Delta Terminal. Het ging bijna in één keer goed. Bijna. De voorgangers van de voorgangers hadden het database-beheer blijkbaar niet zo netjes gedaan. Er waren kennelijk met de hand extra autorisaties op tabellen gezet. Dat leverde wat problemen op. Gelukkig konden we hier uiteindelijk vrij makkelijk iets aan doen.

Maar woensdag uitslapen was er niet bij. De klant klaagde: de vakantieplanning werkte niet meer. Hoe kan dat nou? Dat werkte wel op de test-machine. Het werd uiteindelijk wéér laat, ik ging weer pas na negen uur naar huis.

Wat was er aan de hand? De prutsers hadden een veld in de database groter gemaakt. Maar dat ze hadden niet overal doorgetrokken. Dus nu werden 41 bytes gekopiëerd naar een buffer van 21 bytes. Tja, dan overschrijf je dus 20 bytes zomaar ergens in het geheugen. Of zelfs 100 keer 20 bytes, want er wordt vaak met groepen van 100 elementen gewerkt. Als je zomaar ergens in het geheugen gaat schrijven, dan kan er van alles gebeuren. Het kan het programma laten crashen (dat gebeurde dus op de operationele machine). Het kan geen enkele impact hebben (als dat stukje geheugen toevallig niet gebruikt werd); dat was kennelijk het geval op de testmachine. Maar het kan nog veel erger: er kunnen subtiele en onopgemerkte verminkingen aan de gegevens optreden. Dat merk je pas veeel later, als het te laat is, en zie dan nog maar eens te achterhalen hoe dat kwam.

Donderdag kon ik dus wel uitslapen. Nee hoor, ik kon eindelijk Philip weer eens naar de peuterspeelzaal brengen! En nu heb ik eindelijk weer eens tijd om me te scheren. Uiteraard belde net toen de klant om te melden dat er iets heel erg mis gaat. Maar toen ik dat een kwartier later zag, en terugbelde, bleek het reuze mee te vallen: hij had gewoon zelf een foutje gemaakt.

Philip in de peuterspeelzaal: paasei schilderen

Nog meer gepruts

Waarom maakt iemand een C-functie van 1561 regels? Is het een vorm van job protection (“ik ben de enige die dit snapt, dus niemand anders kan aan dit programma werken, dus ze kunnen me niet ontslaan”)? Of is het omdat ze nooit behoorlijk hebben leren programmeren? Laat ik het maar op het laatste houden. “Never attribute to malice that which can be adequately explained by stupidity.”

Een voorbeeld? Ok.

Ze willen bepalen of er onverwerkt aanbod is. Dus tellen ze eerst al het aanbod, dan tellen ze het verwerkte aanbod, en als er verschil tussen die aantallen is dan weten ze dat er onverwerkt aanbod is. Maar waarom zou je niet meteen gewoon het onverwerkte aanbod tellen? Hup, daar gaan ruim 20 regels weg.

Nog een voorbeeld? Tuurlijk. 't Wordt nu wel een beetje technisch, hoor.

Ze gaan 't een en ander opzoeken in de database, en wat ze vinden voegen ze toe aan een lijstje. Het vergt in dit geval ruim 60 regels code (van de 1561). Er zit een SQL-query in, en die ziet er er zo uit:

SELECT … FROM … WHERE … AND a.ownerid = :uvb_eigenaar;

(Die :uvb_eigenaar is één van de parameters. Ze voeren dit stukje meerdere keren uit, telkens met andere waarden in de parameters.)

Meteen daarna staat een vrijwel identiek stuk code. Dus weer ruim 60 regels. Het enige verschil is één deeltje van de SQL-query. Die ziet er nu zo uit:

SELECT … FROM … WHERE … AND a.ownerid = 1;

Nu hebben we dus 60 regels teveel. We kunnen namelijk ook een aparte functie maken, die we twee keer aanroepen: eerst met :uvb_eigenaar en dan met 1. We hebben dan weliswaar een nieuwe functie van ruim 60 regels, maar de originele functie van 1561 regels wordt zowat 120 regels korter. En als we die nieuwe functie nou ook nog een mooie naam geven, bv. get_onverwerkt_aanbod(), dan snappen we meteen wat 'ie doet, zonder dat we al die code hoeven te bekijken.

Ik kan nog genoeg andere voorbeelden geven, maar dat zal ik jullie niet aandoen.

Frustatie

Ik zit op kantoor. Een paar weken geleden heb ik versie 3.0.0 van Spidi opgeleverd. De klant is nu aan het testen. Soms bellen ze op, om een vraag te stellen, of een probleempje te melden. Zonet nog: “Frans, bij het overwerk van persoon 1212 van 3 maart is de SAP-datumcorrectie niet uitgevoerd”. Ojee. Dat is iets dat de prutsers mijn voorgangers niet helemaal goed en compleet hadden ingebouwd.

Zoek, zoek, waar zit dat ook alweer. In ieder geval in een stuk dat in C is geschreven. Ik hou wel van C. Fijne programmeertaal. Maar ook (of juist) in C kan je heel onleesbare code schrijven. Zie bijvoorbeeld The International Obfuscated C Code Contest.

Oja, 't zit in source file sap_interface.sc. In deze file staan 11 functies. Daarvan zijn er 6 die helemaal niks doen. Vroeger deden ze wel wat, maar 't is niet meer nodig. Normaal gesproken haal je dan die functies helemaal weg, maar alleen maar de functie leegmaken is natuurlijk voor de luie programmeur veel makkelijker. Want dan hoef je niet de aanroepen van die functies weg te halen. Prutsers.

Van de overige functies is er ééntje die er echt uitspringt. Functie uvb_verantwoording(). Die is 1561 regels lang (de hele source file is 1871 regels). Is dat erg, zo'n grote functie? Ja, dat is erg. Erg groot = erg onoverzichtelijk = erg grote kans op bugs en erg moeilijk aan te passen. Zoiets hoor je op te splitsen in een aantal kleinere functies. Prutsers.

Om een lang verhaal kort te maken (had ik maar de tijd om dat met die functie te doen… bah): ik ben niet blij. Ik moet eerst moed verzamelen. Een glaasje drinken, wat met een collega babbelen. Roene kijkt naar zijn iPod, en aan zijn gelaatsuitdrukking te zien is er iets niet helemaal in orde. Toen de accu van z'n iPod bijna op was heeft hij de verlichting van de display uitgezet. En nou blijft die uit, ook als je op de knopjes drukt. Maar als de verlichting uit is, dan kan je het scherm dus niet zien. Helemaal niet. De iPod is nu een spiegeltje. Hoe moet hij nou de verlichting weer aanzetten…? Mijn dag is weer goed. Zelfs bij Apple doen ze domme dingen.

Werknemers in de IT zijn amateurs

Klussen in en om huis, wie kan het niet? Je hoeft niet een schildersopleiding te hebben om je kozijnen te schilderen. (Hmm - dat had ik vier jaar geleden al moeten doen. 't Komt er steeds niet van.) En wie kan niet zelf z'n nieuwe IKEA-meubeltje in elkaar zetten? Elektra en gas, da's al wat ingewikkelder, maar een beetje handige klusser kan ook daarmee een heel eind komen. Toch er is veel wat je eigenlijk niet mag doen. Als je in de meterkast wil gaan rommelen moet je al gauw officiëel gecertificeerd elektro-installateur zijn. Dat heeft een goede reden: het kan gevaarlijk zijn. Voor jouzelf, maar ook voor de overige bewoners van het pand.

Het is ook niet zo moeilijk om software te schrijven. Bijna iedereen kan wel een programmaatje maken. En vreemd genoeg zijn daar weinig of geen wettelijke regels of vereiste certificeringen voor. Veel van de mensen die in de IT werken zijn dan ook amateurs. Misschien hebben ze wel een cursusje of een zelfs heuse opleiding in de juiste richting gevolgd. Maar ook daar leer je helaas niet hoe je op verantwoorde manier software maakt. En dat is te merken. Men maakt er een rommeltje van.

Ik werk nu bij een bedrijfje waar we onderhoud aan oude software doen. Tien of meer jaar is oud in de snelle wereld van de IT. Eén van de centrale bedrijfskritische applicaties is zelfs al meer dan dertig jaar oud (en in COBOL geschreven, natuurlijk). In al die jaren zijn er heel wat verschillende mensen met al die software aan de gang geweest. Waaronder heel wat amateurs. En dat is te merken. Het is een rommeltje.

Deze week moest ik een triviale toevoeging aan een Windows-programma maken. Ik heb heel wat op mijn geachte voorgangers zitten schelden. Het is zo'n rommeltje dat het me veel te veel tijd en moeite kostte om uit te zoeken hoe en waar ik mijn wijzigingen moest doen. Het is een klein wonder dat ik in dat stuk code geen bugs heb gevonden. Dat zal wel komen doordat het functioneel gezien relatief simpel is. En het is al zó lang in gebruik dat eventuele bugs allang gevonden zijn.

Kort geleden kwam ik dit plaatje tegen. Ik denk dat ik elk individueel monster (ook die van part 2) wel eens tegen ben gekomen. Veel van hen meer dan ééns.

Cobol krassen

Na het Euromax-debacle bij Frog ben ik, nu alweer zo'n anderhalve maand geleden, bij RDS terechtgekomen. RDS is een zusterbedrijf van mijn eigen werkgever, ICT. RDS doet het onderhoud van de software voor de ECT-terminals, onder meer de Delta Terminal op de Maasvlakte en (sinds een half jaar) de Home Terminal. Vanuit mijn werkplek in Pernis kijk ik uit op de Home Terminal, dat is leuk. Leuker in ieder geval dan het uitzicht bij Frog: een Utrechtse nieuwbouwwijk.

Zo zit ik dus nog steeds in de software voor containerterminals. Voorlopig werk ik aan de Home Terminal. Jammer genoeg is dat niet echt software om equipment aan te sturen, 't is meer administratieve software. En het is oude software. Heel oude software. De centrale applicatie is al meer dan dertig jaar geleden gemaakt. En dus in een taal geschreven die in die tijd gangbaar was voor administratieve software...: Cobol. Andere delen zijn in Pascal geschreven. Op VMS. De servers waren ooit VAXen, maar die hebben ze gelukkig vervangen door Alpha's.

De afgelopen zes jaar heb ik m'n werk vooral in Java gedaan. Soms JavaScript, C++, C of C#. In ieder geval redelijk hedendaagse talen (jawel, C is ook nog een hedendaagse taal). Op Windows, en soms Linux. Nou, dan is Cobol en VMS toch wel iets heel anders. 't Is weer eens wat -ehm- nieuws. Ik heb ooit stage gelopen bij IBM (op de kop af twintig jaar geleden), en daar heb ik een paar programma's gemaakt in PL/1. Dat is ook al zo'n dino-taal, maar Cobol is nog weer een stapje primitiever.