Technische schuld: betaal alleen rente op wat je gebruikt

Technische schuld is een term die vaak wordt gebruikt om de kosten van het niet direct oplossen van problemen in softwareontwikkeling te beschrijven. Veel teams zien het als een berg werk die moet worden weggewerkt. Dit is een misvatting. Technische schuld is pas een probleem als je er rente op betaalt. Een opruimsprint verlaagt de rekening niet als de onderliggende code niet actief wordt gebruikt of aangepast. De focus moet liggen op de impact van de schuld en de frequentie waarmee de betreffende code wordt aangeraakt.

De analogie van rentekosten op technische schuld

Denk aan technische schuld als een lening. Je betaalt rente over die lening. Hoe hoger de rente, hoe duurder de lening. Bij technische schuld is de rente de extra tijd en moeite die nodig is om nieuwe functionaliteit te bouwen of bestaande code aan te passen. Als code complex is, slecht gedocumenteerd, of vol zit met workarounds, kost elke wijziging meer tijd. Die extra tijd is de rente die je betaalt. Net als bij een hypotheek [3] is het belangrijk om te begrijpen wanneer je rente betaalt en wanneer niet. Een lening voor een tweede huis is bijvoorbeeld niet aftrekbaar, wat de kosten anders maakt dan een lening voor je eigen woning. Zo is het ook met technische schuld: niet alle schuld is even duur.

Waarom een opruimsprint zelden werkt

Een opruimsprint, waarbij teams zich richten op het wegwerken van technische schuld, klinkt logisch. De praktijk wijst echter uit dat dit vaak niet de gewenste resultaten oplevert. Als je een week lang code opruimt die niemand aanraakt, heb je weliswaar de code 'verbeterd', maar de operationele kosten zijn niet gedaald. Je hebt geen rente bespaard. Het is vergelijkbaar met het opruimen van een zolder die je nooit bezoekt. Het is netjes, maar het levert geen directe waarde op. De tijd die je besteedt aan opruimen, kun je niet besteden aan het bouwen van nieuwe functionaliteit die wel waarde toevoegt. Dit is een gemiste kans. De focus moet liggen op de code die actief wordt gebruikt en aangepast, daar waar de rente daadwerkelijk wordt betaald.

Oude code die niemand aanraakt: rente nihil

Stel je voor: een oud stuk code dat al jaren draait. Het doet zijn werk, maar het is niet elegant geschreven. Niemand heeft het de afgelopen vijf jaar aangeraakt. De kans is klein dat het in de nabije toekomst wordt gewijzigd. In dit geval is de rente op deze technische schuld nihil. Het kost geen extra tijd of moeite om nieuwe functionaliteit te bouwen, omdat deze code niet in de weg zit. Het is als een oude auto die in de garage staat en niet wordt gebruikt [4]. Het is misschien niet de nieuwste of de mooiste, maar zolang je er niet mee rijdt, betaal je geen brandstofkosten of onderhoud. Laat deze code met rust. De kosten van het opruimen wegen niet op tegen de baten. Het is een investering zonder rendement.

Een slordige koppeling die vaak wordt aangepast: hoge rente

Een ander scenario is een koppeling tussen twee systemen. Deze koppeling is snel in elkaar gezet, met veel aannames en weinig documentatie. Elke keer dat een van de gekoppelde systemen verandert, moet deze koppeling worden aangepast. Dit gebeurt maandelijks. Elke aanpassing kost extra tijd, omdat de code onoverzichtelijk is en de impact van wijzigingen moeilijk te overzien is. Hier betaal je hoge rente. De frequentie van aanraking is hoog, en de impact van de slordigheid is direct merkbaar in de doorlooptijd van wijzigingen. Dit is de technische schuld die je actief moet aanpakken. Het opruimen van deze koppeling zal direct leiden tot een verlaging van de operationele kosten en een versnelling van de ontwikkeling. Het is een investering die zichzelf snel terugverdient.

Een complex algoritme dat zelden faalt: lage rente

Een complex algoritme dat de kern vormt van een belangrijk onderdeel van de applicatie. Het is moeilijk te begrijpen, zelfs voor de ontwikkelaars die het hebben gebouwd. Het faalt echter zelden en hoeft maar eens per jaar te worden aangepast voor een nieuwe regelgeving. De impact van de complexiteit is hoog, maar de frequentie van aanraking is laag. In dit geval is de rente op de technische schuld relatief laag. Hoewel het pijnlijk is om het algoritme aan te passen, gebeurt dit zo zelden dat de totale kosten meevallen. Het is als een zeldzame reparatie aan een gespecialiseerd stuk gereedschap. Het is duur als het nodig is, maar het is zelden nodig. Het is niet de hoogste prioriteit om dit algoritme te herschrijven. Documentatie en goede tests zijn hier belangrijker dan een complete refactor. Zorg dat de kennis over het algoritme niet verloren gaat, bijvoorbeeld door een gedegen overdracht bij vertrek van een ontwikkelaar [1].

Prioriteren op impact en frequentie

De sleutel tot effectief omgaan met technische schuld is prioriteren. Gebruik een raamwerk dat de impact van de schuld en de frequentie van aanraking combineert. Technische schuld met een hoge impact en een hoge frequentie van aanraking moet de hoogste prioriteit krijgen. Dit is waar de rente het hoogst is. Technische schuld met een lage impact en een lage frequentie van aanraking kan worden genegeerd. Het is belangrijk om te beseffen dat niet alle technische schuld hoeft te worden opgelost. Sommige schuld is acceptabel, zolang de rentekosten beheersbaar blijven. Het is een strategische keuze, geen morele verplichting. Het gaat om het optimaliseren van de ontwikkelingssnelheid en het minimaliseren van de operationele kosten. Dit betekent dat je soms bewust kiest om bepaalde schuld te laten bestaan, omdat de kosten van het oplossen niet opwegen tegen de baten. Het is een pragmatische benadering van softwareontwikkeling.

Technische schuld als strategisch instrument

Technische schuld is geen vijand die moet worden verslagen. Het is een strategisch instrument. Soms is het nodig om bewust technische schuld te creëren om snel een product op de markt te brengen. Dit is een afweging tussen snelheid en kwaliteit. Het is belangrijk om deze beslissingen bewust te nemen en de kosten en baten af te wegen. Als je eenmaal een product hebt gelanceerd, kun je de technische schuld geleidelijk afbouwen, beginnend met de schuld die de hoogste rente genereert. Dit is een iteratief proces. Het is geen eenmalige opruimactie, maar een continu beheer van de codebase. Het is een onderdeel van de dagelijkse praktijk van softwareontwikkeling. Door technische schuld op deze manier te benaderen, transformeer je het van een probleem naar een beheersbaar onderdeel van je ontwikkelingsproces. Het stelt je in staat om sneller te innoveren en tegelijkertijd de kwaliteit van je software te waarborgen.