Onderhoud je webshop en beperk technical debt

Bart de Vries   •  16 mei 2017

Technical debt belemmert de doorontwikkeling van je webshop. Het is niet te voorkomen, maar wel te beperken. Product owners kiezen vaak, ook onbewust, voor functionele oplossingen en niet voor onderhoud. Terwijl onderhoud er juist voor zorgt dat de technical debt beperkt wordt, in plaats van vergroot.

Onderhoud je webshop net als een auto

Misschien heb je iets met auto’s en misschien ook niet, maar je kunt je vast goed voorstellen dat je een klassieke auto er graag goed uit wilt laten zien. Mooie lak, een strakke carrosserie en natuurlijk een soepel draaiende motor. Maar als je al je geld steekt in de vooral optische zaken, hoe ziet de toekomst van je auto er dan uit? Onderhuidse roest, elektronische storingen, slechte remmen en kapotte schokbrekers. Kortom: je moet ook investeren in het onderhoud van de auto.

Het onderhouden van een webshop is niet veel anders dan het onderhouden van een auto. Investeringen in functionele of optische vraagstukken dragen direct bij aan het behalen van de doelstelling. Investeringen aan onderhoud doen we, net als bij een auto, liever niet of met enige tegenzin. Dit item geeft een context aan het doorontwikkelen en onderhouden van een webshop.

Je webshop is rijp voor de sloop?!

Je zet alles in om een zo goed mogelijke webshop te realiseren. Kosten noch moeite worden gespaard om de doelgroep zo goed mogelijk te bedienen. Met name functionele verbeteringen staan bovenaan de backlog en zo maak je mooie stappen voorwaarts!

Met de doorontwikkelingen krijg je op een bepaald moment echter het idee dat ze meer tijd kosten. Je krijgt meer last van kleine inconsistenties en de webshop gaat onduidelijk gedrag vertonen. Kortom: langzamerhand gaat een deel van de investering zitten in het oplappen van roest in plaats van het doorontwikkelen van de webshop.

Het is tijd om de webshop te gaan zien als een langetermijninvestering.

Kwalitatieve software en technical debt zijn een keuze

De onderhoudbaarheid van software wordt onder andere beschreven in een ISO normering (ISO 25010). Grofweg gaat deze normering over de modulariteit, herbruikbaarheid, analyseerbaarheid, wijzigbaarheid en testbaarheid van de code. Bij voldoende aandacht voor deze onderwerpen werk je bewust aan de kwaliteit van je software. Dit betekent echter niet dat de gerealiseerde oplossing functioneel correct of toekomstvast is.

Wat zijn de gevolgen van “slechte” software?

  • Is je modulariteit slecht? Dan loop je het risico dezelfde wijziging op meerdere plekken te moeten doen.
  • Is je hergebruik slecht? Dan is het slechts een kwestie van tijd tot een wijziging die op plaats A wordt doorgevoerd, niet goed wordt doorgevoerd op plaats B.
  • Is de code slordig geschreven? Dan wordt het risico groter dat een ontwikkelaar de code niet meer goed kan lezen en doorgronden.
  • Is je code niet testbaar? Dan blijf je aangewezen op handmatig testen en kun je dus geen geautomatiseerde tests uitvoeren.

Vanaf de eerste regel code begint ook het onderhoud. Nieuwe functionaliteit beïnvloedt namelijk de reeds bestaande code en de nieuwe code wordt weer beïnvloed door de bestaande code. Een minder goed opgezette of matig onderhouden code wordt steeds meer een last waardoor de snelheid van doorontwikkeling terugloopt. Deze “last” wordt in vaktermen “technical debt” genoemd, oftewel: een technische schuld. Een schuld waar inzet voor nodig is om hem op te heffen en waar je rente over betaalt in de vorm van extra werk, omdat het doorvoeren van wijzigingen relatief duurder is.

Je vraagt je misschien af of ‘achterstallig onderhoud’ is te kwantificeren. Met andere woorden: als ik nu kies voor toegevoegde waarde, wat is dan de impact (in uren) op de staat van onderhoud? Helaas is hier geen eenvoudige regel voor, omdat het iets is wat je opbouwt gedurende een langere periode. Dit gaat erover dat het bouwen van software altijd gepaard gaat met het opbouwen van een ‘schuld’ en dat je af en toe even de tijd moet nemen deze weer af te lossen.

Het hebben van technical debt is een feit en niet te voorkomen. Zelfs bij de NASA zal op bepaalde plekken technical debt ontstaan. Technical debt hoeft dan ook niet erg te zijn, maar het moet niet teveel worden.

Kwaliteit van software is niet mijn probleem!

“Jullie zijn toch de specialist op dit vlak, waarom moet ik mij daar zorgen over maken?” Dat klopt, van ons mag je verwachten dat we software bouwen die verantwoord in elkaar steekt. Toch is het wel een samenwerking waarin we moeten zoeken naar de gulden middenweg. Op deze middenweg maken we met elkaar bewuste keuzes in het speelveld tussen ‘toegevoegde waarde’ en ‘duurzame software ontwikkeling’.

In de praktijk zien we twee valkuilen. De eerste valkuil is dat wij, de dienstverlener, te weinig inzage geven in de mogelijke oplossingsrichtingen en de duurzaamheid van iedere oplossing. De tweede valkuil is dat het voor dienstverleners vaak lastig uit te leggen is waarom technisch onderhoud van belang is en dat er soms ook expliciet geïnvesteerd moet worden zonder dat daar een direct toegevoegde waarde voor de klant aan gekoppeld is. Kortom: deze adviestaak is voor een product met een langere termijnvisie van groot belang.

Het belang van het advies is nog groter als je bedenkt dat jij, de klant of de product owner, uiteindelijk bepaalt of we investeren in functionaliteit of in onderhoud. En hoe kun je nu een goede keuze maken wanneer je onvoldoende geïnformeerd of geadviseerd bent? Dat neemt echter niet weg dat ook jijzelf een verantwoordelijkheid hebt in het afwegen van toegevoegde waarde ten opzichte van onderhoud. Uiteraard wil je graag zoveel mogelijk waarde toevoegen aan de webshop en zo min mogelijk aan onderhoud. Maar wat als het matige onderhoud er uiteindelijk toe gaat leiden dat er fouten ontstaan, inconsistenties de kop op steken of uitbreidingen ineens heel kostbaar worden?

Bewust keuzes maken

Uiteindelijk gaat het erom dat we met elkaar bewuste keuzes maken. Keuzes tussen onderhoudbaarheid en toegevoegde waarde. Soms kies je voor de toegevoegde waarde op korte termijn, soms voor het inlossen van een schuld en dus voor onderhoud voor de lange termijn.

Als leverancier zetten we ons in om je zo goed mogelijk mee te nemen in deze afwegingen. Met elkaar kunnen we dan keuzes maken en bouwen aan een vruchtbare toekomst, waar snel geanticipeerd kan worden op de behoeften van de doelgroep. Op die manier dragen we ook bij aan het realiseren van jouw doelstellingen!

Bart is teamlead Techniek. Binnen De Nieuwe Zaak houdt hij zich bezig met de technische doorontwikkeling van de projecten en het aansturen van het technisch team.
Blijf op de hoogte

Meld u aan voor onze wekelijkse e-commerce nieuwsbrief en blijf op de hoogte van het laatste e-commerce nieuws!

© 2017 De Nieuwe Zaak

Mis het niet...

Onze experts verzamelen wekelijks het laatste e-commerce nieuws voor u. Meld u nu aan voor de nieuwsbrief en blijf op de hoogte!

Liever updates op uw tijdlijn? Volg dan De Nieuwe Zaak op: