Waarom investeren in de kwaliteit van software als een goedkopere oplossing ook goed functioneert en bovendien sneller wordt opgeleverd? Met andere woorden: is software van een hogere kwaliteit het prijsverschil waard ten opzichte van minder kwalitatieve applicaties? Een vraag die ook Martin Fowler zich stelt in zijn artikel: Is high quality software worth the cost? Met dit artikel in het achterhoofd stelden enkele collega’s zichzelf dezelfde vraag, het antwoord lees je hieronder.
Hoewel Fowler doorgaans het technische schrijven niet uit de weg gaat, neemt hij
in dit blogbericht een standpunt in dat zowel aan technische als aan businesszijde voet aan grond vindt. In zijn betoog gaat Fowler dieper in op de
afweging tussen prijs en kwaliteit en legt hij ook uit
wat softwarekwaliteit inhoudt. Kleine spoiler: kwaliteit heeft niet voor iedereen dezelfde betekenis.
Vervolgens doet hij de introductie van het concept “cruft”: het verschil tussen de code zoals ze bestaat en de code zoals ze er idealiter zou uitzien. Hoe groter dit verschil tussen de realiteit en het ideale, hoe meer cruft en hoe groter de kost, in tijd en geld, om de software aan te passen of uit te breiden. Bovendien neemt met de hoeveelheid cruft ook de foutenlast in de code toe. Cruft is op deze manier sterk verweven met de interne kwaliteit van een applicatie.
Een applicatie waarbij de zorg voor de architectuur, of interne kwaliteit, beperkt blijft zal dus sneller worden opgeleverd. Toekomstige features bijbouwen en aanpassingen doen zal dan weer meer tijd vragen. Doorgaans is de initiële tijdsachterstand voor een applicatie met een verzorgde architectuur al na enkele weken terug ingelopen. Vanaf dat punt is het zelfs zo dat de applicatie met de hogere kwaliteit goedkoper is en sneller evolueert dan een slordige variant.
Om samen de vatten: Fowler vindt het verschil in initiële kostprijs om een kwalitatieve architectuur op te zetten meer dan waard. Bovendien zijn deze applicaties op lange termijn goedkoper, hebben ze een lagere foutenlast en gaan ze langer mee. Fowler besluit met het onderuithalen van de titel van zijn blogpost en geeft aan dat de meerkost van kwalitatieve software negatief is, en dus een opbrengst is.
Wat we er zelf over denken?
Enkele van onze consultants hebben het artikel ook gelezen en uiteraard hebben ze hier wat over te zeggen. Vanuit verschillende functies en ervaringsniveau kijken en herkennen ze dezelfde problematiek: vaak denkt men op te korte termijn en is er te weinig tijd om aan de kwaliteit van de code te sleutelen, hoewel dat in de toekomst een wereld van verschil betekent.
Wannes Geboers - Junior developer
Hoewel mijn eigen ervaring nog beperkt is, beeld ik me wel steeds in hoe mijn code zou moeten zijn. Bedrijfsnormen of coding conventions helpen hierbij en verhogen de eenvormigheid en de kwaliteit van je werk en vergemakkelijken het reviewen. Dat geldt ook voor een correcte naamgeving.
In theorie is het logisch dat je altijd kiest voor de duurzame en kwalitatieve oplossing. De praktijk echter, leert me dat je niet steeds van nul kan beginnen en eens iets scheef groeit je het moeilijk terug recht krijgt. Soms zit er niets anders op dan verder te bouwen op functionerende maar wankele constructies.Mogelijk ontdek je dan na implementatie dat een andere oplossing even goed of misschien zelfs beter had uitgedraaid. Dan is dat een kans om mee te nemen in je leerproces en dezelfde fouten in de toekomst te vermijden.
Martijn Vandevyvere – Freelance Architect
Zelf kan ik alleen maar bevestigen dat crufty software rechttrekken een werk is van lange adem en een enorme kost met zich meebrengt. De bereidheid van de meeste bedrijven om hierin te investeren ontbreekt na de initiële kost van het project, tenzij men bij het maken van nieuwe functionaliteit voldoende hinder ondervindt. Vaak kan de kwaliteit beter gegarandeerd worden indien er tijd wordt gestopt in een juiste opzet.
Echter, zoals het artikel beschrijft, wordt een opzet gebaseerd op assumpties die doorgaans aan het begin van een project worden gemaakt. De visie waarnaar de software op langere termijn zal evolueren is hier key. Als deze ontbreekt of te beperkt is zullen de initiële assumpties na verloop van tijd heel vaak incorrect blijken.
In het artikel wordt de vergelijking gemaakt met de architectuur van een gebouw dat gedurende de uitbouw van het project of product wijzigt. Persoonlijk vind ik de analogie met de aanleg van een tuin meer gepast. Je kan dit perfect plannen, maar tijdens de opbouw van de tuin mag je de reeds gerealiseerde stukken niet verwaarlozen, anders krijg je met wildgroei te maken. Als dan blijkt dat ook het aanpalende perceel deel moet uitmaken van de tuin, maar dat de huidige aanplanting de doorgang onmogelijk maakt, moeten er grote wijzigingen worden doorgevoerd in de architectuur om deze bijkomende vraag te ondersteunen. Deze analogie leunt meer aan bij de overtuiging dat software binnen een ecosysteem past en dus continu onderhevig is aan veranderingen.
Kortom, een oog voor architectuur en de opbouw van een code base zijn essentieel om de interne kwaliteit van software hoog te houden alsook de code toegankelijk en gemakkelijk aanpasbaar te houden. Echter is het belangrijk om dit steeds binnen een bepaald timeframe te bekijken. De input van vandaag is die van morgen niet, noch die van volgend jaar. We hebben er dus alle baat bij om onze code zo clean mogelijk te houden.
Kristof Dieltjens – Senior Consultant
Het zou fantastisch zijn als dit artikel ook aan businesszijde wordt gelezen, ik ben helemaal akkoord. Als je softwaredevelopers de tijd geeft om de code proper op te leveren, zal je daar uiteindelijk de vruchten van plukken. Nieuwe features krijgen sneller vorm en worden zo na enige tijd dus ook goedkoper om te ontwikkelen.
Ik ben ook voorstander om bij de start van een project de architectuur zo simpel mogelijk te houden. Naarmate nieuwe functionaliteiten worden toegevoegd, kan indien nodig ook de complexiteit van de architectuur groeien. Met een simpele opzet is de hoeveelheid code beperkt en dat maakt het eenvoudiger om de code cruft-vrij te houden.
Daarnaast opteer ik voor een opzet met continuous delivery, een agile softwareontwikkelmethode gericht om op kortcyclische wijze businessvragen te valideren en te verwerken en zo sneller tot een eindproduct te komen.
Dit vraagt iets meer tijd bij de aanvang van het project maar biedt voordelen. Het vergemakkelijkt het onderhoud of uitbreidingen van de architectuur in de toekomst. Kom je tijdens de ontwikkeling van een nieuwe feature wat crufty code tegen, kan je dat herwerken en meenemen in de volgende release. Zo verbeter je op een proactieve manier de ontwikkeling en interne kwaliteit van je software.
Het verdict is unaniem: software met een doordachte en kwalitatieve architectuur heeft ook onze voorkeur. We trachten dit uit te dragen en bedrijven te wijzen op het feit dat de levensduurte van software langer is dan de initiële oplevering. Het is logisch dat uitbreidingen van de software steeds eenvoudiger tot stand komen vanuit een ordelijke en duidelijke architectuur. Het is dan ook onze taak als softwareleverancier om in samenspraak met onze klanten de juiste opzet te bepalen en uit te bouwen.
Broed je op een nieuwe businessapplicatie die jouw bedrijf hoger op de ladder zet?
We helpen je graag met de geschikte aanpak.
Neem contact op