Softwarekwaliteit door meester-gezelprincipe

Het seminar stond in het teken van meten aan software. Een voortreffelijk verlopend ontwikkel- of beheerproces wil nog niet zeggen dat de software zelf ook voortreffelijk is. Dit gezien vanuit de invalshoeken software risk, security en technical debt. Opvallend was dat de zaal niet vol zat, terwijl de kwaliteit van de gepresenteerde inhoud goed was en de paneldiscussies onderhoudend en nuttig waren. De leeftijd van de aanwezigen was gevorderd. Ik viel wat dat betreft niet uit de toon.

Bewustzijn

Gaandeweg de dag ging het steeds meer over bewustzijn. Sterker nog, zoals dat gaat onder gelijkgestemden, over het gebrek aan bewustzijn. Bewustzijn bij het management, dat te veel nadruk legt op kosten en zich te weinig bewust is van de (afbreuk)risico’s van software-met-een-historie, waardoor geld voor refactoring niet beschikbaar is. ‘The risks they accept are huge’, zei een van de sprekers. Maar ook over het bewustzijn bij jonge projectleiders, architecten en software engineers. Op deze groep concentreerde zich het genoemde lunchgesprek.

Het schrijven van toekomstbestendige software wordt zwaar onderschat

De Amerikaanse IT-professional sprak met enige verbolgenheid over de jonge in een bepaalde technologie gecertificeerde software engineer. Of beter, hoe die gekwalificeerd wordt in het algemeen. Die certificering lijkt een vrijbrief om ingezet te worden op complexe softwareprojecten, terwijl er van enige ervaring geen sprake is. De moeite die het kost om software te schrijven die toekomstbestendig is, wordt zwaar onderschat. Door zijn Texaanse tongval kwam bij mij de teneur van zijn verhaal over, de precieze bewoordingen eerlijk gezegd niet. Ik noemde het meester-gezelprincipe en de man begon helemaal te stralen.

Meester en gezel

Het meester-gezelprincipe ben ik tegengekomen bij de garagist in de kleine gemeente waar ik woon. Ik ben blij met hem. Mijn Mercedes uit 1973 (zie foto) liep, nadat hij de carburateur had afgesteld, 205 km/u. De man heeft veel ervaring en denkt na voordat hij wat doet. Die combinatie is goud waard, ook bij moderne auto’s. Bij moderne auto’s doen zich vaak samengestelde problemen voor: een roetfilter slibt dicht, waarop sensoren reageren, waarop het motormanagementsysteem reageert. De meting van het diagnosesysteem kan als oorzaak heel iets anders aangeven dan wat er feitelijke aan de hand is. Mijn garageman zoekt dan door en vervangt niet klakkeloos.

Om deze vaardigheden en kennis over te brengen hanteert de garagist het meester-gezelprincipe. Zijn jonge, net beginnende monteurs worden eerst op kleinere klussen gezet. Daarna, en dat is sterk, lopen ze een tijd met hem mee. Ze ervaren, zien en voelen. Ze kijken de kunst af. En na 3 à 5 jaar kunnen ze echt zelfstandig werken. Hij zorgt voor veiligheid, waardoor jongens langere tijd blijven.

Bij software gaat het vaak om samengestelde problemen

Is deze metafoor passend voor software engineering? Het zou kunnen zijn dat meesters zeggen: ja. Bij toekomstbestendige software gaat het ook om ervaring en nadenken voordat je wat doet. En bij software gaat het vaak om samengestelde problemen. En de gezellen zeggen waarschijnlijk: nee, de meesters remmen ons. Wij acteren agile en een app hoeft niet toekomstbestendig te zijn. Tegen die tijd is de app al achterhaald.

Subtiel

Een collega (meester: ruim 20 jaar ervaring) past naar eigen zeggen het meester-gezelprincipe subtiel toe bij reviewing van een aanpassing of uitbreiding van code. ‘Ik maak geen document met wat er anders moet, daarmee de ander (gezel) aan zijn lot overlatend. We gaan gezamenlijk door de code heen en via pair programming refactoren we de losse eindjes. Dat scheelt een hoop formeel gedoe. Tijd en kennis worden een-op-een overgedragen.’

Rest de vraag: hoe zouden de gezel – die meester is in vernieuwend denken en gewend is aan deze snelle wereld – en de ‘oude meester’ optimaal kunnen samenwerken?