Waarom de kwaliteit van software achterloopt op de levering van software

Het snel leveren van software is belangrijk om functionaliteit aan eindgebruikers te leveren, maar de kwaliteit van de software kan daardoor tekortschieten. Er kan op een ‘listige manier’ een oplossing worden gebouwd, die gunstig is op de korte termijn maar niet op de lange termijn. In de praktijk zie ik dat organisaties zich meer richten op levering dan op kwaliteit. Met drie redenen leg ik in deze blog uit waarom de kwaliteit van software achterloopt op de levering van software.

1 – Geen duidelijke criteria voor de kwaliteit van software

De criteria voor het op tijd leveren van software zijn vrij duidelijk: Er is een bepaald doel waarvoor er moet worden gebouwd, een aantal user stories, en er is een deadline om dit op een bepaald moment te leveren. Tegenwoordig worden de meeste projecten op een vlugge manier gedaan, zodat er minimaal één softwarerelease per maand is. Er is misschien wat discussie over wat het exacte doel was en de deadline kan misschien een paar dagen worden opgeschoven, maar de deadline en het doel van de release zijn tastbare criteria.

Maar, hoe meet je dan de kwaliteit van software? Hoewel er misschien ISO-normen zijn waar dit mee gedaan kan worden, is kwaliteit altijd specifiek voor een bepaalde context en organisatie. De softwarekwaliteit kan in variabelen worden uitgesplitst, maar ik heb gezien dat die aan persoonlijke smaak onderhevig zijn en dat deze veranderen naarmate er andere mensen bij worden betrokken. Als de softwarekwaliteit in te veel variabelen wordt uitgesplitst, valt er niet meer mee te werken. En als het er maar een paar zijn, is het te simplistisch. Ook kunnen er objectieve metingen worden verricht die de softwarekwaliteit niet op een goede manier weergeven. En wanneer de kwaliteit niet volgens verwachting is, gaat de discussie vaak meer over de uitsplitsing van de variabelen dan over de metingen. Vanwege de onduidelijke criteria, wordt het concept softwarekwaliteit onaantastbaar en onwerkbaar. Als gevolg daarvan wordt de kwaliteit van software niet echt op een structurele manier gemeten.

Een collega zei eens tegen me dat ‘er gebeurt wat er wordt gemeten’’/wat wordt gemeten is wat er gaat gebeuren’. Deze opvallende uitspraak verklaart waarom de levering van software beter wordt beheerd dan de kwaliteit van software.

2 – Vertraagd effect van slechte softwarekwaliteit

Het effect van een late levering van software is op korte termijn zichtbaar: het bedrijfsleven en de eindgebruikers verwachten nieuwe functionaliteit en oplossingen voor hun applicatie. Nieuwe en betere functionaliteit is waarin de eindgebruiker met name is geïnteresseerd. Stel je voor dat je pech met de auto hebt, dan wil je dat je auto zo snel mogelijk wordt gerepareerd. Als (wordt verwacht dat) een softwarelevering niet op tijd is, worden er maatregelen genomen door de bouwteams aan te zetten om iets extra’s te doen en de verwachtingen van de belanghebbenden bij te stellen. Dagen of weken voor het moment van ‘going live’ wil de verantwoordelijke voor de levering bepalen of de levering doorgaat of niet.

Het effect van slechte softwarekwaliteit wordt pas op de lange termijn gevoeld. Als we teruggaan naar het voorbeeld van autopech, is het voor de bestuurder belangrijker dat de auto is gerepareerd dan hoe de auto is gerepareerd. Maar als hetzelfde probleem met de auto zich twee maanden later weer voordoet, was er misschien een probleem met de manier waarop de auto werd gerepareerd. De kenmerkende kwaliteitsproblemen die ik heb gezien, vertonen zich pas op een later moment:

• Het aanbrengen van kleine wijzigingen aan bestaande onderdelen vergt meer tijd dan nodig is vanwege de ‘alternatieve code’ en de codelogica. De ontwikkelaar die de wijziging moet aanbrengen, moet de bewerking op de eerste alternatieve oplossing uitvoeren.
• De code is niet op een begrijpelijke manier neergezet en er zijn geen aantekeningen gemaakt, dus is het moeilijk voor de andere (nieuwe) ontwikkelaars om te begrijpen hoe de oplossing werkt.

De slechte kwaliteit van de software is (logischerwijs) het meest zichtbaar voor de ontwikkelaars die met de software werken. Het is minder zichtbaar voor architecten en vrijwel niet zichtbaar voor eindgebruikers en het bedrijf. Daarom duurt het langer voordat het probleem zichtbaar is en daarmee de benodigde aandacht van het management krijgt. Omdat de teams van ontwikkelaars vooral worden beoordeeld op wat zij leveren en minder op hoe zij bouwen, zijn zij geneigd om liever voor een korte- dan voor een langetermijnoplossing te kiezen.

3 – Het effect van slechte softwarekwaliteit is niet eenvoudig te begrijpen.

Het is makkelijker om te begrijpen waarom software te laat wordt geleverd. En omdat de softwarelevering wordt gemeten, wordt er automatisch tijd toegewezen om de knelpunten en mogelijke oplossingen te onderzoeken.

De software wordt vooral goed begrepen door de ontwikkelaars en architecten en kan zeer complex zijn, het is niet altijd eenvoudig om te onderzoeken hoe verschillende softwareonderdelen bijdragen aan bepaalde effecten. En zelfs wanneer het voor ontwikkelaars duidelijk is, is het niet altijd eenvoudig om het aan het bedrijf en de eindgebruikers uit te leggen. En omdat de softwarekwaliteit nou net niet op een structurele wijze wordt gemeten, wordt er minder ‘officiële” tijd toegewezen om de effecten te onderzoeken.

Hoe meer aandacht te krijgen voor softwarekwaliteit?

Zoals ik eerder al heb uitgelegd, loopt de kwaliteit van software achter op de levering van software. De criteria van softwarekwaliteit zijn onaantastbaar, het effect is op de korte termijn niet zichtbaar en het is moeilijker om de effecten van de software(kwaliteit) te begrijpen. Het is echter wel belangrijk om de manier waarop de applicatie wordt gebouwd te begrijpen en hier controle op te houden en om de kwaliteit te meten. Het is heel belangrijk om na te gaan denken over het meten van de softwarekwaliteit vanaf het begin van een project en niet halverwege het project. Zorg ervoor dat deze kwaliteitscriteria worden afgestemd en ondersteund binnen de organisatie.