Beginnend met ponskaarten in het begin van de jaren 1980, leerde Ger Cloudt waardevolle lessen over het ontwikkelen van goede software. De nieuwe trainer van het High Tech Institute deelt zijn inzichten over de wisselwerking tussen processen en vaardigheden, over het meten van softwarekwaliteit en over het stimuleren van een organisatiecultuur waarin engineers software van hoge kwaliteit kunnen leveren.
Ger Cloudt kwam voor het eerst in aanraking met programmeren door het gebruik van ponskaarten tijdens zijn studie elektronica aan de Fontys Hogeschool Venlo in het begin van de jaren tachtig. Na zijn afstuderen begon hij aan een carrière als digitaal elektronicus, waarbij hij zich zowel richtte op het ontwerpen van digitale schakelingen als op het ontwikkelen van software om microprocessoren aan te sturen. “Dit was in assembler en ik herinner me dat ik echt ongestructureerde spaghetti-code maakte,” herinnert Cloudt zich. “Dit maakte het natuurlijk buitengewoon moeilijk om problemen op te lossen en bugs te repareren, waardoor ik een harde les leerde dat er een betere manier moest zijn.”
Gelukkig werd Cloudt tijdens zijn tweede opdracht gekoppeld aan een ervaren mentor die hem leerde om te beginnen met gestructureerde pseudocode en deze vervolgens om te zetten in assembler. “Dit was de eerste keer dat ik ervoer dat structuur het maken van robuuste code kan vergemakkelijken en het debuggen makkelijker kan maken.” Deze ervaring leidde er uiteindelijk toe dat hij een paar jaar later overstapte naar softwareontwikkeling.
Proces versus vaardigheid
Cloudt ging bij Philips Medical Systems werken als softwareontwikkelaar en later als softwarearchitect, waar hij leerde hoe processen en vaardigheden elkaar aanvullen. “Om acties uit te voeren, heb je een bepaald vaardigheidsniveau nodig, terwijl om resultaten te bereiken, acties gestructureerd moeten worden door een proces. Het belang van proces of vaardigheid hangt echter af van het soort taak. Aan de ene kant zijn er taken zoals lopendebandwerk of het bouwen van Ikea-meubels die je hebt gekocht, waarvoor een strikt proces nodig is, maar minimale vaardigheidseisen. Aan de andere kant zijn er taken zoals het schilderen van de Mona Lisa, zoals Leonardo da Vinci deed, die minder afhankelijk zijn van processen maar een hoog vaardigheidsniveau vereisen dat slechts weinigen bezitten.”
''I increasingly believed that skill level is more important than processes for software engineers. A process can facilitate applying your skills, but with inadequate skills, no process will help.''
In deze periode zag Cloudt een sterke nadruk op processen bij softwareontwikkeling. “Dit was de periode van de opkomst van het Capability Maturity Model, gericht op het verbeteren van softwareontwikkelingsprocessen. Maar zelfs met processen blijven vaardigheden essentieel. In het streven naar hoge CMM-niveaus is het onderwaarderen van vaardigheden een reëel gevaar.” Dit inzicht werd verder versterkt toen Cloudt overstapte naar managementfuncties bij Philips Medical Systems, waar hij leiding gaf aan teams van zestig mensen. “Het bereiken van een specifiek CMM-niveau wordt al snel een doel op zich, en zoals de Wet van Goodhart zegt: als een maatregel een doel wordt, is het geen goede maatregel meer. Ik ben er steeds meer van overtuigd geraakt dat het vaardigheidsniveau belangrijker is dan processen voor software engineers. Een proces kan het toepassen van je vaardigheden vergemakkelijken, maar met ontoereikende vaardigheden zal geen enkel proces helpen.”
Cloudt leerde vervolgens over het belang van transparantie. “In mijn eerste functie als kwaliteitsmanager moest ik een probleem oplossen waarbij twee verschillende softwarestacks moesten worden geïntegreerd. Het ene team ontwikkelde NFC-software, het andere werkte aan software voor een beveiligd element. Het integreren van beide bleek een uitdaging. Toen ik er dieper op in ging, ontdekte ik dat de teams hun software weliswaar testten, maar dat testfouten niet systematisch werden gemonitord. Dus maakten we dagelijks bijgewerkte dashboards met testresultaten en bespraken de ontwikkelaars dagelijks de uitkomsten. We deelden de dashboards zelfs met de klant. Natuurlijk zag alles er aanvankelijk rood uit, maar dit diende als een sterke stimulans voor de ontwikkelaars om zich te verbeteren. En zo slaagde het project.”
Leren door te delen
In zijn rol als software R&D manager bij Bosch begon Cloudt de behoefte te voelen om zijn inzichten over softwarekwaliteit te delen. Hij begon met het delen van artikelen op het interne sociale netwerk van het bedrijf en op Linkedin. “Ik kreeg veel positieve feedback, vooral van Bosch collega’s,” zegt hij. “Dus in 2020 besloot ik een boek te schrijven: ‘Wat is softwarekwaliteit? Deze ervaring was erg verrijkend, omdat het veel van mijn impliciete kennis expliciet maakte en ook hiaten in mijn kennis blootlegde.”
In een kwaliteitscommissie bij Bosch ontmoette Cloudt een jonge afgestudeerde met een masterdiploma in kwaliteitsmanagement. Toen hij vroeg of de afgestudeerde een cursus over softwarekwaliteit had gevolgd, was het antwoord negatief. “Dit was voor mij aanleiding om het Engineering Doctorate programma van de Technische Universiteit Eindhoven te benaderen, waar ze me uitnodigden om een gastcollege te geven. Uiteindelijk werd ik docent voor een cursus kwaliteitsmanagement.” Cloudt begon ook te spreken over softwarekwaliteit op evenementen, zoals een Bits&Chips-evenement in 2021 en hij lanceert momenteel twee trainingsprogramma’s bij het High Tech Institute, een voor ingenieurs en een voor managers. Zijn huidige functie is softwarekwaliteitsmanager voor de ontwikkeling van het Digital Application Platform bij ASML.
Softwarekwaliteit meten
Softwarekwaliteit als zodanig is niet meetbaar, stelt Cloudt, vanwege de diversiteit van het concept. “Je kunt een aantal specifieke aspecten van softwarekwaliteit meten, die bekend staan als ‘gemodelleerde kwaliteit’. Deze omvatten cyclomatische complexiteit van code, afhankelijkheden, codedekking, aantal regels en open bugs. Zulke metrieken zijn nuttig, maar iedereen die er doelen op stelt moet op zijn hoede zijn voor de Wet van Goodhart.”
Een essentieel onderdeel van kwaliteit blijft onmeetbaar: transcendente kwaliteit. Om dit te illustreren vergelijkt Cloudt het met het beoordelen van een schilderij. “Je kunt de dikte van de verf en de afmetingen van het doek meten, maar je kunt de schoonheid van het schilderij niet meten. Hetzelfde geldt voor softwarekwaliteit: je kunt de codedekking van je unit tests meten, maar dat bepaalt nog niet of de tests goed zijn. Daar heb je een expert opinion voor nodig, ondersteund door de gemodelleerde kwaliteit die je meet.”
''Never underestimate culture. An organization should foster an environment where software engineers can thrive and deliver excellent design, code and product quality.''
Als mensen aan softwarekwaliteit denken, noemen ze vaak aspecten als modulariteit, schone code en bruikbaarheid. Dit zijn voorbeelden van ontwerpkwaliteit (bijvoorbeeld modulariteit, onderhoudbaarheid en scheiding van zorgen), codekwaliteit (bijvoorbeeld schone code, overdraagbaarheid en unit tests) en productkwaliteit (bijvoorbeeld bruikbaarheid, veiligheid en betrouwbaarheid). Volgens Cloudt vereisen deze drie soorten kwaliteit echter een element dat vaak over het hoofd wordt gezien: organisatorische kwaliteit. “Dit type kwaliteit bepaalt of je organisatie in staat is om software van hoge kwaliteit te bouwen. Aspecten als software vakmanschap, volwassen processen, samenwerking en cultuur zijn van vitaal belang voor organisatorische kwaliteit. Onderschat cultuur nooit. Een organisatie moet een omgeving koesteren waarin software engineers kunnen gedijen en uitstekende ontwerp-, code- en productkwaliteit kunnen leveren.”
Bedoeld en geïmplementeerd ontwerp
Er zijn verschillende bekende best practices voor het ontwikkelen van software van hoge kwaliteit, waaronder testgedreven ontwikkeling (TDD) en pair programming, naast statische codeanalyse. Cloudt voegt daar iets aan toe dat minder gebruikelijk is: statische ontwerpanalyse. “Veel mensen realiseren zich niet dat er een verschil is tussen het beoogde ontwerp en het geïmplementeerde ontwerp van software. Software-architecten documenteren hun beoogde ontwerp in UML-modellen. Er is echter vaak een kloof tussen dit beoogde ontwerp en de implementatie ervan in code. Het is een best practice om dit gat klein te houden. Tools kunnen controleren op consistentie tussen je code en UML-modellen en waarschuwen als er discrepanties ontstaan.”
Deze kloof tussen het beoogde en het uitgevoerde ontwerp ontstaat vaak onder tijdsdruk, bijvoorbeeld vanwege deadlines van projecten. “In zulke gevallen neem je een kortere weg door een oplossing te ‘hacken’ waarmee je de deadline haalt, met minder nadruk op kwaliteit,” legt Cloudt uit. “Dit is een bewuste keuze om technische schuld te introduceren vanwege tijdsdruk. Hoewel dit misschien de enige directe oplossing is, is het cruciaal om deze technische schuld later aan te pakken. Nadat de release is opgeleverd, moet je tijd vrijmaken om een goede oplossing van hoge kwaliteit te ontwikkelen. Helaas gebeurt dit niet vaak. Managers moeten de noodzaak inzien om ontwikkelaars de tijd te geven om dit gat en deze technische schuld te verkleinen om toekomstige problemen te voorkomen. Door hun beslissingen dragen managers in belangrijke mate bij aan de kwaliteit van de organisatie en hebben ze een directe invloed op de kwaliteit van software.”
Dit artikel is geschreven door Koen Vervloesem, freelancer voor Bits&Chips.
De trainingen 'Softwarekwaliteit voor engineers' en 'Begrijpen van softwarekwaliteit voor managers' worden twee keer per jaar gehouden.
Blijf op de hoogte
Ontvang onze maandelijkse updates
