De business case voor software-kwaliteit

Het is vaak lastig om een goede business case te maken voor verbetering van software-kwaliteit. Dit komt door de ‘software-onderhouds-paradox’. In dit artikel leggen we uit hoe men toch de business case kan bepalen.

Het meten van software-kwaliteit

Elk systeem dat in productie is genomen heeft onderhoud nodig. De software zelf die veroudert niet, maar de business-omgeving verandert waardoor elk jaar tussen de 5% en 25% van de functionaliteit moet worden gewijzigd. De moeite en kosten van deze wijzigingen lopen echter uiteen: bij sommige systemen zijn zelfs de kleinste wijzigingen lastig en kostbaar, omdat de code niet goed onderhoudbaar is. Met name voor bedrijven waar systeem lang mee moeten gaan (banken, verzekeraars, logistiek) is dit een groot probleem. Om deze problemen te voorkomen, investeren veel bedrijven in het meten en verbeteren van de software-kwaliteit en onderhoudbaarheid. Dit kan met behulp van kwaliteitsmodellen als ISO 25010, het SIG / TÜViT sterrenmodel en hulpmiddelen zoals Sonarcube en andere software-meet-tools (zie hier een lijst van bekende software-meettools).

Effect op lopende projecten

Het grote voordeel van het meten van software-kwaliteit is dat het automatisch zorgt voor meer aandacht voor kwaliteit. Voor veel scrumteams zijn de meldingen over kwaliteit, zelfs als ze alleen maar symptomen aanwijzen,  een aanleiding om extra aandacht te besteden aan bepaalde stukken code. Als metrieken op deze manier gebruikt worden dan is er altijd een kwaliteitstoename toe te verwachten. Agile teams zijn daarom meestal enthousiast over het meten van software, zolang dat gebeurt door het team om het team meer inzicht te geven.

Het is echter lastig om dit enthousiasme ook te vertalen in een concrete business case. Bij beginnende projecten is dit geen groot probleem, omdat er vaak geen grote investering nodig is om de code-kwaliteit omhoog te brengen. Bij bestaande software is er echter vaak wel een tijdsinvestering om bestaande bevindingen op te ruimen, en is er dus vraag naar een goede business case. In de praktijk is deze niet eenvoudig te maken.

Waarom is een business case lastig?

De eenvoudigste business case voor alle investeringen in bestaande software, is het effect op de onderhoudskosten. Hierbij kijk je of een investering in bijvoorbeeld verbeteren van onderhoudbaarheid leidt tot een afname van onderhoudskosten, wordt deze vanzelf terugverdient. Om dit effect te onderzoeken hebben we voor meer dan 100 systemen bij een tiental bedrijven gekeken naar de relatie tussen de onderhoudbaarheid van software en de jaarlijkste kosten van software-onderhoud. Hier kwam een paradoxaal resultaat uit:

• Systemen met een lagere score voor onderhoudbaarheid hebben vaak lagere onderhoudskosten.

Men zou dit de software-onderhouds-paradox kunnen noemen, want het effect is tegengesteld van wat men zou verwachten. Gelukkig is er een verklaring: er wordt vaak noodgedwongen minder onderhoud gedaan aan slecht onderhoudbare systemen. Dit heeft twee grondoorzaken:

• Omdat wijzigingen in een slecht onderhoudbaar systeem duur en lastig zijn, werkt men om het systeem heen. Men doet de wijzigingen in systemen naast of voor het slecht onderhoudbare systeem als dat mogelijk is.
• Er zijn vaak onvoldoende mensen beschikbaar die aan het systeem kunnen en willen werken, waardoor belangrijk onderhoud niet op tijd gedaan wordt. Dit leidt tot problemen voor de business maar ook tot lage directe kosten.

Oplossingen voor de business case

Om toch het belang van goede onderhoudbaarheid aan te tonen, moet men daarom kijken naar andere effecten dan alleen kosten. De volgende positieve effecten hebben we gezien in de praktijk:

• Langere levensduur. Bij goed onderhoudbare systemen is er minder noodzaak om een vervangend systeem te ontwikkelen
• Snellere oplostijden. Bij slecht onderhoudbare systemen kost het vaak maanden om een release te maken, en blijven fouten daardoor maandenlang overlast geven. Bij goed onderhoudbare systemen is het mogelijk om binnen enkele weken tot zelfs dagen verbeteringen te doen

Deze twee effecten zijn goed meetbaar. Het effect van snellere oplostijden is aangetoond door onderzoek op open source systemen door Dennis Bijlsma, een voormalig collega van de mensen van SoftwareZaken.  In de grafiek hiernaast, afkomstig uit de thesis van Dennis Bijlsma, is dit effect te zien. De kwaliteit staat horizontaal (0-5 sterren), de oplostijd in dagen staat verticaal. Het is duidelijk te zien dat het in twee-sterrensysteem lang duurt voordat een probleem opgelost is (meer dan 50 dagen). Voor een meer dat gemiddeld onderhoudbaar systeem (4 sterren) is het slechts 10 dagen. De donkere lijn geeft bugs aan, de lichte lijn verbeteringen.

Toepassing in de praktijk

In de praktijk is gebleken dat er niet voor ieder systeem een goede business case is om te investeren in softwarekwaliteit: voor sommige systemen loont het wel maar voor andere systemen niet. De belangrijkste factoren en overwegingen zijn de volgende:

• Als een systeem een sleutelrol heeft in een belangrijk proces, wordt vaak gekozen om te investeren in verbetering. De reden is dat bedrijven aantoonbaar in control moeten zijn van toezichthouders. In dit geval is investeren in kwaliteit altijd zinvol.
• Bij kleine systemen is verbetering eenvoudiger en goedkoper en is er vaak een goede business case. Bij grote systemen is de business case vaak ongunstig.
• Als een systeem net opgeleverd is, is verandering eenvoudiger omdat de kennis nog vers is en het oorspronkelijke team beschikbaar. Bij oudere systemen is dit niet zo en is de business case voor verbetering minder gunstig

De eenvoudigste manier om te bepalen of het zinvol is om te investeren in software-kwaliteit, is door een kort code-onderzoek te doen waarin gekeken wordt naar omvang van het systeem en huidige onderhoudbaarheid. Met SoftwareZaken doen we regelmatig dit soort onderzoek, om vervolgens een onderbouwd advies te kunnen geven.

Image credit: Creative commons Humusak via Pixabay