Iedereen wil software die werkt, waarin bugs goed en snel kunnen worden opgelost en waarbij nieuwe features snel kunnen worden toegevoegd. Kwaliteit is daarom cruciaal in software. Maar hoe waarborg je als bedrijf die softwarekwaliteit? En hoe kun je als management softwareontwikkeling het beste aansturen en engineers motiveren? Een aantal experts ging over deze en andere vragen met elkaar in gesprek tijdens een rondetafel, georganiseerd door Link Magazine en Tiobe.
Han Schaminée: ‘Als engineer heb je eigenlijk maar twee keuzes. Je kunt de buffer die je hopelijk hebt ingebouwd inzetten óf inleveren op kwaliteit.’
– ‘Uiteindelijk gaat het over de total cost of ownership.’
– ‘Als je verbeteringen wilt doorvoeren, moet je laten zien wat het oplevert.’
– ‘Software is niet af als het wordt opgeleverd.’
– ‘Machines moeten meer dan 99 procent uptime hebben, dus is een hoge softwarekwaliteit nodig.’
– ‘Het helpt echt om eindgebruikers dichter bij je IT-teams te brengen.’
Wensen van het management komen lang niet altijd overeen met die van IT
Kwaliteit is een lastig begrip, zeker als het om software gaat. Want wat houdt softwarekwaliteit precies in? En hoe meet je dat? Kijk je naar het aantal openstaande bugs? Of naar hoe makkelijk je nieuwe features kunt toevoegen? Voor de deelnemers aan de rondetafel is dit dagelijkse kost, maar een eenduidig antwoord lijkt er niet te zijn. Vaak wordt in ieder geval gekeken naar de hoeveelheid fouten. Richard Sweer, projectmanager NextGen AODB (Airport Operational Database, red.) bij de Schiphol Group geeft een voorbeeld: ‘Je weet hoeveel fouten er per regel code zijn en wat de benchmark is. Er zijn gewoon een aantal metrics die je in de gaten moet houden. Als we die grens overschrijden, releasen we niet. Daarin word ik ook op executive-niveau gesteund.’
‘Kwaliteit ontstaat niet vanzelf’
Het alleen oplossen van bugs is echter niet voldoende, meent Bob Peters, vice president engineering bij TomTom, fabrikant van navigatiesystemen. ‘Het is belangrijk dat je ook naar de oorzaak kijkt. Anders blijf je bugs oplossen, maar doe je niet meer dan brandjes blussen. Je wilt ook weten waarom er fouten worden gemaakt en dat oplossen.’ Bovendien zijn bugs voor lang niet iedereen een belangrijke maatstaf voor kwaliteit, benadrukt Thijs Hekelaar, enterprise architect bij Bronkhorst, dat gespecialiseerd is in low flow fluidic handling oplossingen ‘Bij ons vindt een manager het aantal openstaande bugs nauwelijks interessant. Die vindt het belangrijk hoe de klant iets ervaart.’
Bepalende kenmerken
Ervaringen zijn daarentegen subjectief; wat door de ene klant wordt bejubeld, is bij de ander een doorn in het oog. Is er wel een eenduidig antwoord op wat kwaliteit inhoudt? Er zijn in ieder geval twee standaarden die beschrijven wat softwarekwaliteit is: de ISO 25010 en de ISO 5055. Deze standaarden kijken bijvoorbeeld naar de betrouwbaarheid, onderhoudbaarheid, beveiliging, flexibiliteit en efficiëntie om te bepalen hoe hoog de kwaliteit van software is.
Bob Peters van TomTom: ‘‘Het is belangrijk dat je ook naar de oorzaak kijkt van problemen. Anders blijf je bugs oplossen, maar doe je niet meer dan brandjes blussen.’
Bugs spelen dus zeker een rol, maar zijn wat deze standaarden betreft slechts één onderdeel van wat software kwalitatief goed of slecht maakt. Want wat maakt het aantal bugs in je software uit als je ze nauwelijks kunt oplossen doordat je software dermate slecht in elkaar zit dat je eigenlijk niets meer kunt wijzigen? Of als je geen nieuwe features meer kunt opleveren voor klanten, omdat het toevoegen van iets nieuws bijna niet meer lukt?
Lars Hoogweg van Lely: ‘We confronteren mensen met de kwaliteit, door ze een dagje mee te laten lopen met de boer.’
‘Uiteindelijk gaat het over de total cost of ownership’, vindt ook Lars Hoogweg, head of farm management software bij Lely Industries, producent van robots en datasystemen voor de melkveehouderij en bekend van de volautomatische melkrobots. ‘Dat is iets wat het management moet uitdragen.’
Spanningsveld
Daarmee rijst direct de vraag: welke rol speelt het management in softwarekwaliteit? Zeker in IT is immers constant sprake van een spanningsveld: de wensen van de business komen lang niet altijd overeen met die van IT. Waar business misschien graag nieuwe features ziet waarmee ze klanten blij kunnen maken, besteedt IT liever tijd aan het beter onderhoudbaar maken van software, waardoor deze uiteindelijk beter presteert.
‘Je moet heel bewust kiezen of je iets oplost of niet’
‘Machines moeten meer dan 99 procent uptime hebben, dus er is een hoge softwarekwaliteit nodig. Tegelijkertijd willen we meer features voor hetzelfde geld. Innovaties om die uptime te behalen zijn misschien minder zichtbaar, maar wel onderdeel van de kwaliteit. Daarin moeten we een balans zien te vinden’, geeft Arjen Klomp, senior software competence manager bij Thermo Fisher Scientific als voorbeeld. Dit bedrijf levert wereldwijd analytische instrumenten, klinische ontwikkelingsoplossingen, gespecialiseerde diagnostiek, laboratorium-, farmaceutische en biotechnologische diensten.
Die balans is wel te bewaken, mits er een goede vertaalslag wordt gemaakt naar het management, ziet Klomp. Als software niet goed te onderhouden en slecht aanpasbaar is, duurt het immers veel langer voor een nieuwe feature kan worden toegevoegd. ‘Als je verbeteringen wilt doorvoeren, moet je laten zien wat het oplevert. Dus maak het management duidelijk dat als zij nieuwe features belangrijk vinden, ze deze verbeteringen ook moeten ondersteunen en daarvoor ruimte en budget moeten geven. Kwaliteit ontstaat niet vanzelf. Hiermee stralen we als management uit dat we kwaliteit belangrijk vinden.’
Kenniskloof
Probleem bij dit onderwerp is vaak dat er een kenniskloof is tussen IT en management, waardoor het lastig kan zijn om in te schatten wat prioriteit heeft. Een oplossing kan zijn om de IT-teams zelf veel verantwoordelijkheid te laten nemen, denkt Hoogweg. ‘Als je de totale ownership bij die teams neerlegt, behaal je wel wat. Maar dan moeten ze ook nee durven zeggen tegen de projectleiders. Dat spanningsveld moet je als management ondersteunen.’
Han Schaminée: ‘Als engineer heb je eigenlijk maar twee keuzes. Je kunt de buffer die je hopelijk hebt ingebouwd inzetten óf inleveren op kwaliteit.’
Tegelijkertijd kan alle verantwoordelijkheid bij IT neerleggen ook te ver gaan, ziet Han Schaminée. Hij is al jaren in verschillende rollen actief binnen de IT-wereld, onder meer als onderzoeker op het gebied van productiviteit in softwareontwikkeling en als zzp’er. ‘Ik hoor managers zeggen: “Jij bent verantwoordelijk, jij moet het oplossen.” Maar als engineer heb je eigenlijk maar twee keuzes. Je kunt de buffer die je hopelijk hebt ingebouwd inzetten óf inleveren op kwaliteit. Maar je kunt niet aan de echte knoppen draaien, zoals de specificaties, samenwerking met de klant of de keuze om meer mensen aan te nemen.’
Gernot Eggen van ASML: ‘Technical debt vormt vaak pas een probleem als je er echt tegenaan loopt.’
Van achter naar voren: Laurens Jansen (Tiobe), Eveline Meijer (Link magazine), Bob Peters (TomTom), Gijs Boekema (Cyclomedia), Paul Jansen (Tiobe) en links Thijs Hekkelaar (Bronkhorst).
Klomp lost dit bij Thermo Fisher op door vier keer per jaar een planningssessie te organiseren met alle stakeholders. ‘Dan kunnen we het gesprek aangaan over wat we nu echt willen hebben en daarop sturen. En als het niet past binnen de beschikbare tijd, wat kunnen we dan doen om toch op te leveren wat waarde heeft? Het is belangrijk om die discussie te hebben. Die empowerment geven we teams steeds meer.’
Tijdsdruk
Wie de kwaliteit van zijn software zo hoog mogelijk wil hebben, neemt bij voorkeur ruim de tijd om hiermee bezig te zijn. Maar IT is een beroep waarin de werkdruk notoir hoog ligt. Zo hoog zelfs, dat 8,8 procent van de IT’ers dit in 2021 als belangrijkste reden gaf voor werkverzuim, aldus het CBS in 2022. In dit onderzoek wordt veel geklaagd over tijdsdruk, vaak als gevolg van personeelstekort en slechte planningen. Wie de kwaliteit van zijn software wil verbeteren, moet hier dus ook rekening mee houden.
Gijs Boekema van Cyclomedia: ‘Software is niet af als het wordt opgeleverd.’
Zeker bij softwareontwikkeling blijkt dat nog een uitdaging, ziet Klomp. ‘Bij hardware is kwaliteit een gegeven. Als de hardware niet goed genoeg is, krijg je het niet werkend. Er is dus altijd een bepaalde basiskwaliteit. Voor software is dat moeilijker te bepalen, omdat het minder direct zichtbaar is.’ Schaminée vult aan: ‘Een nieuwe versie van hardware maken is ook moeilijker.’ Als dat nodig is, moet immers al snel een heel nieuw product worden verscheept. Bij software kunnen gemakkelijk constant updates worden uitgerold.
Juist dat zorgt echter voor een heel ander probleem: wanneer is iets klaar? ‘Software is niet af als het wordt opgeleverd’, ziet ook Gijs Boekema, product owner Street Smart, API’s and Integration bij Cyclomedia, dat grootschalige systematische visualisaties van fysieke omgevingen levert. ‘Er zit een stukje nazorg in. Dus wat is je definitie van klaar?’
Technical debt
Kijkend naar de kenmerken van softwarekwaliteit die de standaarden hanteren, blijken onderhoudbaarheid en aanpasbaarheid twee belangrijke kenmerken te zijn. Daarmee is ook technical debt een belangrijk aspect voor softwarekwaliteit. Technical debt is vergelijkbaar met geld lenen. Wie geld leent, heeft daar op korte termijn voordeel van: er is geld binnen om wat mee te doen. Maar dat bedrag moet uiteindelijk wel worden terugbetaald, vaak met rente. Bij technical debt geldt eenzelfde principe. Ontwikkelaars behalen op de korte termijn voordeel, bijvoorbeeld door iets op een minder mooie manier te maken en daarmee tijd te besparen. Maar op de lange termijn zorgt dat er ook voor dat code misschien minder goed te onderhouden is. Blijf je alleen maar technical debt opbouwen, dan wordt het steeds lastiger om de software te onderhouden en aan te passen, waardoor het langer duurt voor nieuwe features kunnen worden toegevoegd en bugs worden opgelost. De schuld wordt immers alleen maar groter.
Thijs Hekkelaar van Bronkhorst: ‘Als de engineers denken “hier ga ik niet aan meedoen”, heb je dus alsnog een probleem.’
Het is dus van belang om de schuld tijdig in te lossen. Bij Thermo Fisher lossen ze dat op door altijd tijd in te ruimen om hiermee aan de slag te gaan, vertelt Klomp. ‘We geven teams in elke sprint een budget om aan technical debt te werken. Het is aan het team zelf om dat dan ook te doen, en op welke manier. Elk team bepaalt zelf hoe ze daarvan gebruikmaken. Het is een goede manier om teams daar zelf eigenaarschap over te geven.’
Bij chipmachinefabrikant ASML wordt steeds bewust gekeken of technical debt moet worden opgelost, zegt Gernot Eggen, manager software (platform) architectuur bij het Veldhovense bedrijf. ‘Technical debt vormt vaak pas een probleem als je er echt tegenaan loopt. Je moet dit dus inplannen in je productportfolio, zodat je er wat mee kunt als je dat gebeurt. Als je elke engineer zo’n budget geeft, dan kijken ze alleen maar naar hun eigen scope en niet daarbuiten. Ik denk echt dat je heel bewust moet kiezen of je iets oplost of niet. Ik ga mijn huis immers ook niet schilderen als ik ga verhuizen.’
Productiviteit als maatstaf
Als management kan het echter lastig zijn om te bepalen of iets echt technical debt is of niet. Vaak vergt dat gedetailleerde kennis over niet alleen IT, maar ook over de software in kwestie. Kennis die bij het management doorgaans ontbreekt. ‘Wij hebben een apart team met architecten die meedenken en het hele plaatje overzien, en hoe technical debt van een team invloed heeft op het hele systeem’, zegt Klomp.
Arjen Klomp van Thermo: ‘Het helpt echt om eindgebruikers dichter bij je IT-teams te brengen.’
Eggen laat teams in termen van productiviteit uitleggen waarom er aan technical debt moet worden gewerkt. ‘Als bij ons iemand zegt: “Ik heb een probleem, maar als ik dat oplos, ga ik zoveel procent sneller”, dan maak je het direct inzichtelijk voor het management. Je hebt een bepaalde rente bij technical debt. Druk die rente uit en dan is het direct duidelijk.’
Dan is wel de vraag: hoe bepaal je de productiviteit? ‘Bij Schiphol meten we op ISO-standaarden en met DORA (DevOps Research and Assessment, red.)-metrieken. Daar kun je heel objectief mee meten’, zegt Sweer. Binnen zijn bedrijf wordt ook een strenge standaard gehanteerd over hoeveel technical debt er mag zijn: ‘Teams mogen niet meer dan twee sprints technical debt hebben. Is het meer, dan moet het worden opgelost.’
Link magazine oktober/november 2024. Thema: Data delen in de keten, cybersecurity en beveiliging. Vraag exemplaar op: mireille.vanginkel@linkmagazine.nl
Paul Jansen van Tiobe was gastheer van het Rondetafelgesprek over Softwareontwikkeling.
Een andere optie is om bijvoorbeeld te kijken naar de output van een team: hoe vaak sturen ze nieuwe code in en hoe goed is die code? ‘Koppel dat aan de backlog in een projectmanagementtool zoals Jira en je kunt per team zien hoeveel wijzigingen ze in een bepaalde tijd doen en wat de kwaliteit daarvan is’, verklaart Klomp.
Waarde duiden
Aan tafel wordt in ieder geval duidelijk dat management een belangrijke rol speelt bij softwarekwaliteit. Maar de engineers zelf zijn net zo belangrijk. ‘Bij Bronkhorst is kwaliteit een onderdeel van de bedrijfscultuur. Dat vindt het management belangrijk. Engineers gaan dan uit zichzelf voor kwaliteit, ook zonder uitdrukkelijke sturing daarop’, zegt Hekelaar. ‘Als de engineers denken “hier ga ik niet aan meedoen”, heb je dus alsnog een probleem.’ Paul Jansen, oprichter en ceo van Tiobe in Eindhoven, dat gespecialiseerd is in het beoordelen en tracken van de kwaliteit van software, beaamt dat: ‘Je kunt bijvoorbeeld ook wel zeggen dat je een nieuwe tool gaat gebruiken om beter te werken, maar dan trappen engineers soms al snel op de rem, omdat hun bordje al vol ligt. Je moet dus duidelijk maken waarom je dat doet.’
Dus hoe motiveer je je software-engineers om zich zo veel mogelijk voor kwalitatief goede software in te zetten? Wat Peters van TomTom betreft, is het heel belangrijk om de kwaliteit inzichtelijk te maken via metrieken: ‘Focus dan niet alleen op de features, maar op alles. Dan maak je duidelijk waarom je dit doet.’ Er ontstaat dus meer intrinsieke motivatie als een engineer weet waar hij of zij aan werkt en wat de waarde daarvan is.
Lars Hoogweg van Lely: ‘We confronteren mensen met de kwaliteit, door ze een dagje mee te laten lopen met de boer.’
Bij Lely wordt een meer praktische aanpak gekozen, vertelt Hoogweg. ‘We confronteren mensen met de kwaliteit, door ze een dagje mee te laten lopen met de boer. Op die manier zien engineers zelf in de praktijk hoe hun software wordt gebruikt en waar nog problemen zitten.’ Bij Bronkhorst is in het verleden een vergelijkbare aanpak ingezet, vertelt Hekelaar. ‘Het is wel voorgekomen dat mensen die niet in de productie werken, zoals software-engineers, op drukke momenten daar wel meedraaiden. Die moesten dus met hun eigen product gaan werken. Dan zie je opeens heel handige functies ontstaan, die ze zelf hebben gebouwd en een dag later konden gebruiken.’
Klomp beaamt dat dergelijke aanpakken werken: ‘Het helpt echt om eindgebruikers dichter bij je IT-teams te brengen. We brengen de softwareontwikkelaars bij Thermo Fisher zo veel mogelijk bij de machines en eindgebruikers, zodat ze begrip opbouwen en tot betere oplossingen komen.’
De deelnemers hebben naar elkaar uitgesproken om op regelmatige basis bij elkaar te komen om met elkaar in gesprek te gaan over de productiviteit van softwareontwikkeling. Eind januari komt de groep wederom bij elkaar om te praten over re-use van software. Wilt u informatie over het platform, neem dan contact op met John van Ginkel Link magazine(john.vanginkel@linkmagazine.nl) of met Laurens Jansen van Tiobe(laurens.jansen@tiobe.com).
