Programmeurs lijden de dans (deel 2)

Dat is eigenlijk mijn ICT-wens en hoop voor 2004. Beter programmeren, boven alles.

Het probleem is dat dit niet zo leuk “bekt”. Het is niet cool. Het is saai. Wie test er nu in godsnaam graag software? Wie houdt zich bezig met steeds opnieuw runnen van een stuk code, er data in te stoppen, kijken wat het doet, software aanpassen en opnieuw beginnen? Wie vindt dit nu een leuk artikel om te lezen?

Misschien nog dit: het meest verrassende interview was met de blitse jonge collega. Een jonge knaap, één jaar afgestudeerd, helemaal niet de perfectionist zoals zijn oudere collega. Maar de knaap, die vandaag verder bouwt aan de software die door zijn collega werd gemaakt, vertelde me dat hij, omwille van de “mooie code”, beïnvloed werd om zelf “mooie code” te schrijven. Heeft u dit ook niet? Stel, u komt binnen in het huis van uw vrienden. Alles ligt er rommelig bij. Het tapijt zit vol vlekken en de deurmat is niet te vinden. U stapt toch zonder problemen met vuile voeten binnen? Dan komt u bij die andere vrienden, waar alles kraaknet is en fris geurt. Instinctief zoekt u naar de deurmat en begint u toch uw voeten te vegen, niet? Er is dus hoop!

Het klinkt toch wel echt cliché hé? Een ernstige, niet-blitse programmeur die met een “maverick-project” iedereen overtroeft. Zo echt iets dat in het rijtje van “eerlijk duurt het langst” past. Iets dat, zelfs in deze moeilijke economische tijden, niet past bij het snelle ritme van onze huidige samenleving. Maar het is een feit waar je niet omheen kunt.

Wie de laatste jaren softwareontwikkelings-conferenties en -seminaries heeft bijgewoond, heeft vastgesteld dat men nog amper praat over goed programmeren. We hebben het wel over “anders programmeren”. Xtreme Programming is toch stukken beter dan OO. En usability is toch een vak waarvoor je minstens twee universiteitsdiploma’s nodig hebt: Informatica en Psychologie, eventueel aangevuld met een taalopleiding.  En testen. We moeten beter leren testen! Meer gestructureerd. De testers moeten automatiseren. De software zo maken dat ze testbaar is met automatisch testtools. We moeten gespecialiseerde testers in huis halen…ONZIN! We weten allemaal dat achteraf corrigeren stukken duurder is dan voorkomen!

Programmeer grondig!

Hoe moeten wij dit aanpakken?

Ik ben het u verplicht om, na al die zwartgalligheid en kritiek aan uw adres (misschien leest u dit artikel al lang niet meer), toch een voorzet tot oplossing te geven. Ik stel een “eenvoudige oplossing” voor die maar op twee pijlers gebaseerd is. Waarom twee? Omdat ik na 4 jaar nadenken over dit probleem – zolang al zit dit ei in mijn hoofd - geen derde kon vinden.

Pijler één: Eenvoud.

Maak eenvoudige code. Maak een eenvoudige architectuur. Doe moeite om eerst grondig je algoritme in kaart te brengen en maak ze dan zo eenvoudig mogelijk. Ik ben in mijn vrije tijd een beetje timmerman. Wie timmert weet dat er honderd methodes zijn om twee stukken hout aan elkaar vast te maken. Wie ervaring heeft, weet dat de meest eenvoudige methode altijd het meest kwalitatieve resultaat geeft.

Neem dus de tijd en maak een decompositie van een wellicht complex probleem tot eenvoudige componenten. Eenvoud betekent ook dat je soms beter herbegint dan bestaande software gaat aanpassen of patchen.

Eenvoud vraagt tijd! We hebben allemaal al ondervonden dat sommige mensen de meest moeilijke dingen heel makkelijk kunnen voorstellen. Deze mensen zijn altijd mensen die lang over dat probleem of die theorie hebben nagedacht.

Pijler twee: Isoleer

We hebben allemaal, onder druk van de wetgever, ons huis geïsoleerd voor warmte. Hierdoor hebben we een lage milieuvervuiling als gevolg van de verwarming van onze huizen. In software geldt deze wet ook: Isoleer, wil je vervuiling van je IT-omgeving tegengaan. Als je een softwarecomponent bouwt, dan ben je als bouwer verplicht om te weten wat de impact is van die component op zijn omgeving en dan moet die impact gecontroleerd en beschreven zijn.

Te vaak denken we dat de input/output-parameters de enige interfaces zijn. We staan niet (genoeg) stil bij de cpu-impact, de memory-impact etc. Wie besluit om op de eerste verdieping van zijn gerenoveerde woning een marmeren badkamer te installeren en zich alleen bekommert om de grootte van het bad, zodat het door de deur kan, die weet, meestal te laat, dat het gewicht ook zijn relevantie heeft…Natuurlijk moet de bouwer van het huis (operating system) u vertellen wat de draagkracht is. Maar als u het niet weet, dan blijft het u verantwoordelijkheid om de nodige omzichtigheid aan de dag te leggen.

Wat weet je als programmeur van de isolatiecoëfficiënt van je software? Hoe ga je die bepalen? Denk daar eens over na.

Het hoeft geen betoog dat isoleren makkelijker is in een “eenvoudige software-architectuur” dan in een “Italiaanse software-architectuur”.

Dit is dus mijn hoop voor 2004: de professionalisering van de programmeur.

En om het leed wat te verzachten, ik kijk ook uit naar de professionalisering  van de managers die echt weten wat software ontwikkelen is.

Ik wens u een aangenaam jaar en een goede gezondheid toe.

Het eerste deel van deze column werd vorige week gepubliceerd.

Auteur: Jens Pas (CEO I2B, Innovatie-advies) 
jens.pas@i2b.be

Wie wil reageren op deze colum moet zich eerst lid maken van de ZI business club, waarna hij/zij dan via het paswoord toegang krijgt om een reactie te plaatsen.