Hoe behouden we professionaliteit in de IT?
Bij het gebruik van dergelijke tools dient men wel met de beperkingen rekening te houden. Mijn ervaring is dat men geneigd is om tools aan te passen aan specifieke situaties. Meestal breekt dit in de exploitatiefase op. Zo herinner ik mij een bedrijf dat een ontwikkel-tool gebruikte om eenvoudige functies - toevoegen, wijzigen, raadplegen, verwijderen van records, et cetera - te ontwikkelen. Dit tool is later zodanig aangepast dat ontwikkelaars in de gegenereerde code, op vooraf gedefinieerde plaatsen, code mochten toevoegen. Na een upgrade van het besturingssysteem en het ontwikkel-tool moesten een aantal in productie zijnde programma’s op schermniveau worden aangepast. Een ontwikkelaar voerde de wijzigingen door in de data dictionary en startte vervolgens het generatieproces. In de exploitatiefase kwamen er echter problemen aan het licht: de functionaliteit van de programmatuur was op verschillende punten niet meer gelijk aan de oorspronkelijke en bedoelde functionaliteit. Het kostte ongeveer twee manjaren om uit te zoeken wat het probleem was. Tijdens eerdere onderhoudscycli waren wijzigingen in de gegenereerde code aangebracht, waar dit niet toegestaan was. Alle behaalde tijdwinst was in één klap tenietgedaan. In veel organisaties wordt documentatie van ontwikkelde systemen gezien als overbodige kostenpost. Vaak wordt daarom besloten om alleen nieuwe systemen goed te documenteren. Immers, de gebouwde software functioneert, en de documentatie wordt nagenoeg nooit meer ingekeken. Hetzelfde geldt voor onderhoud. Dat moet zo goedkoop mogelijk zijn. Door deze ‘besparingen’ ligt de kwaliteit en de onderhoudbaarheid van de gebruikte systemen ernstig onder druk. Test- en onderhoudstrajecten worden voornamelijk gebaseerd op de bestaande documentatie en bij afwezigheid daarvan op kennis van een beperkt aantal personen. Bij het geheel of gedeeltelijk ontbreken van deze zaken is kwaliteit niet meer te leveren. In een testtraject kan men de volledigheid van de test niet bepalen, terwijl in een onderhoudstraject niet meer kan worden vastgesteld of een bepaalde wijziging volledig en op de juiste plaats(en) is uitgevoerd. Ik heb een bedrijf meegemaakt wat al tien jaar een systeem hanteerde waarin door de veranderende producten in de onderliggende database een aantal structuurwijzigingen moesten worden doorgevoerd. Vlak voor oplevering van de aangepaste programmatuur, bleek in één van de programma’s jaren eerder een aantal ongedocumenteerde filters te zijn geplaatst. Hierdoor werd 60 procent van de code van achterliggende programma’s niet uitgevoerd. Bij onderzoek bleek dat de meeste tijd (65 procent) van het wijzigingstraject in het aanpassen en testen van die code was gaan zitten. Door een in het verleden behaalde ‘besparing’ van 50.000 gulden ging er nu een bedrag van 500.000 euro verloren. Het inzetten van traditionele programmeurs in moderne trajecten levert problemen op. Een procedureel systeem ontwikkelen is iets anders dan een systeem wat gebaseerd is op objecten. Goede ouderwetse programmeurs, opgeleid in het gebruik van procedurele talen, kunnen niet zo maar worden ingezet in trajecten waar op basis van Object Oriëntatie wordt gewerkt. Overigens geldt het omgekeerde ook. Daarom pleit ik voor de in Nederland nauwelijks bekende rol van Chief Programmer. Zo’n functionaris kan in vele van de hierboven geschetste situaties uitkomst bieden. Het is een manager met diepgaande en brede technisch inhoudelijke kennis. Daarnaast heeft deze ook een goed en volledig beeld van de organisatie waarin hij/ zij werkzaam is en een goed onderbouwde visie op de inzet van IT binnen de organisatie. Hij/zij is bij uitstek geschikt om een IT-afdeling te managen. Naast manager is het ook een uitstekend mentor en heeft hij/zij voldoende bagage om een goede bewaking van de geleverde kwaliteit te implementeren, zonder dat andere stakeholders in het gedrang komen. De Chief Programmer zou als de ‘missing link’ in IT-land kunnen worden gezien. Johan Kentie is senior consultant bij Astis Automatisering BV te Utrecht.