Technical debt is de schuldenlast die ontstaat bij softwareontwikkeling doordat ontwikkelaars kiezen voor een oplossing die op korte termijn gemakkelijker te implementeren is, maar die op langere termijn minder wenselijk en moeilijker te onderhouden is. Vaak gaat het om een snelle oplossing (shortcut) waarvan de code later moet worden aangepast. In de praktijk gebeurt dat vaak niet alleen door tijdsdruk of de dagelijkse hectiek. Tech debt kan ook ontstaan doordat software te vroeg wordt vrijgegeven, doordat te weinig tijd is genomen voor het ontwerp van de architectuur of door het ontbreken van goede documentatie bij de opgeleverde code. 

De opgebouwde schuld zorgt voor hogere beheerkosten, doordat extra tijd en geld gaat zitten in herstelwerk. En ook niet onbelangrijk: het beperkt de innovatiekracht en bedrijfsprestaties. De vergelijking met financiële schulden stamt uit 1992 toen deze technische ontwikkeling voor het eerst werd vergeleken met financiële schuld. Die zorgt ook voor extra kosten (rente) en ook in dit geval kunnen de kosten zich steeds verder opstapelen. De bedenker van de naam is programmeur Ward Cunningham, tevens uitvinder van het wiki-concept.

Een kleine technical debt is niet zo erg. Maar zodra de schuld oploopt, heeft dit grote gevolgen voor een organisatie en de IT-afdeling. Bij een meerderheid van de bedrijven is dat al voelbaar. Maar liefst 69% van de IT-professionals beschouwt tech debt als grote bedreiging voor het innovatievermogen van hun bedrijf, toont dit internationale onderzoek. In Nederland is dat niet anders, want het is een universeel probleem. Volgens 61% van de IT-professionals remt het de bedrijfsprestaties. Gemiddeld wordt 41% van het IT-budget besteed aan de technische schuld. Dit betreft bedrijven in alle sectoren en de technische schuld groeit (ook procentueel) wanneer bedrijven groeien. Een groot probleem is dat organisaties hierdoor veel kansen missen om structureel te kunnen innoveren.

Tech debt op zich is niets nieuws. Die is er altijd geweest en – zoals gezegd – wanneer de omvang beperkt blijft, hoeft het niet zo erg te zijn. Wel ernstig is de toenemende omvang nu er steeds meer code nodig is voor alle digitalisering en innovatieprojecten. Bovendien worden de mensen die deze projecten realiseren steeds schaarser. Dat zet extra druk op ontwikkelteams, waardoor een grotere schuldenlast al snel op de loer ligt. In het onderzoek wordt voor de schuldengroei geen eenduidige oorzaak genoemd, maar wel een reeks factoren die het verklaart. Zoals het gebruik van veel ontwikkeltalen en frameworks (genoemd door 52% van de ondervraagden), verloop binnen ontwikkelteams (49%) en het accepteren van bekende defecten om releasedeadlines te halen (43%). En doordat organisaties het oplossen uitstellen, blijft het probleem groeien. Slechts 20% zegt dat hun tech debt goed beheersbaar is. 

Low-code softwareontwikkeling kan uitstekend helpen om de technical debt weer te beperken en goed beheersbaar te houden. Hierbij plaats ik wel een kanttekening: ook in dit geval moet je zorgvuldig werken, want doordat low-code ontwikkelaars zelf minder code hoeven te schrijven, leveren ze meer code af. Door die grotere productiviteit kun je ook meer technische schuld opbouwen als teams een aantal uitgangspunten niet goed naleven. 

Bij Synobsys werken we met het low-code platform van OutSystems. Diverse slimme tools helpen onze developers hierbij actief om tech debt te voorkomen. Bijvoorbeeld door codekwaliteit te meten, hiervoor aanbevelingen te doen en te waarschuwen wanneer dat nodig is. In het ontwikkelplatform zijn best practices ingebouwd op het gebied van architectuur, security en performance. Daarnaast is integratie van externe bronnen eenvoudig te realiseren. Hierdoor wordt de infrastructurele debt vermeden. Ook kiezen wij in onze werkwijze samen met opdrachtgevers heel bewust voor het beperken van de schuldenlast. Wij eisen van onze developers dat de schuld in ieder geval niet toeneemt en waar mogelijk zorgen wij ook actief voor het verkleinen. Ontwikkelaars zien op hun dashboard continu de actuele stand van zaken van het project waar zij aan werken. 

Als OutSystems MVP zie ik bij onze projecten toe op de kwaliteit van de code en geef ik gevraagd en ongevraagd advies aan onze low-code ontwikkelaars. Zo zorgen we dat de code netjes modulair is opgebouwd. Ons streven is om te zorgen dat de code eruitziet alsof het door één persoon geschreven is. In de praktijk is die ‘utopie’ misschien nooit helemaal te realiseren, maar daar moet je in onze ogen wel naar streven. Bij Synobsys hebben we altijd hoge kwaliteitseisen gesteld. Daardoor hebben we destijds ook gekozen voor ons huidige ontwikkelplatform. Hiermee en met goede codeerrichtlijnen en naleving daarvan kunnen we ons dashboard voor de oplevering altijd zo groen als gras laten kleuren. Dan weten we dat het goed zit.

In het algemeen is het voor opdrachtgevers vaak slecht te zien hoe het ervoor staat met hun technische schuldenlast. Die ervaren ze vaak pas op langere termijn. Er zijn wel zaken die zij kunnen doen om hun tech debt te beperken. Dat begint met het bewustzijn en streven naar de beoogde kwaliteit in werkprocessen en met de gebruikte tools zoals het (low-code) ontwikkelplatform. Bepaal samen met een team wat acceptabel is en werk aan het meten en waar nodig terugdringen van de schuldenlast. Ook uitgebreid (laten) testen is waardevol.

De beste manier om tech debt aan te pakken, is door het te voorkomen. Wanneer de last al groter is, worden vaak bepaalde symptomen zichtbaar. De code wordt ‘onbeheersbaar’ of ontwikkelaars worden overdreven gespecialiseerd. Ik zal dit illustreren met twee voorbeelden.

Voorbeeld 1: Om in een bepaald stuk code te werken, krijgen ontwikkelaars regelmatig te horen dat ze hiervoor eerst bij collega X moeten aankloppen. Die heeft de code gemaakt en weet als enige hoe het in elkaar steekt. Zo ontstaat sterke afhankelijkheid én een bottleneck in ontwikkelprocessen. Dat is voor geen van de betrokkenen een prettige situatie en een goede reden om eens goed naar de schuldenlast te kijken.

Voorbeeld 2: Het kan ook gebeuren dat bij het opschalen van projecten de ontwikkelsnelheid structureel sterk blijkt te dalen. Dit kan bijvoorbeeld gebeuren als een bestaande applicatie een jaar of tien oud is, met complexe code terwijl veel developers uit de begintijd al weg zijn. Als je dan opschaalt, gaat de snelheid (velocity) omlaag. Het inwerken van nieuwe mensen kost extra veel tijd, niet alleen tijdens de eerste sprints, maar ook voor de langere termijn. En voordat nieuwe mensen de echt complexere vraagstukken kunnen oppakken, ben je nog veel langer onderweg.

Naast de indicatoren uit de zojuist genoemde voorbeelden zijn er meer indicatoren die wijzen op een grote of groeiende technische schuldenlast. Ook zonder tools die dit meten, kun je de technical debt herkennen. Op termijn is merkbaar dat de beheerskosten en het deel van het IT-budget dat hiervoor nodig is, omhoog gaan. Maar vaak is het probleem ook al eerder te signaleren. Bijvoorbeeld doordat een applicatie minder flexibel wordt en de ontwikkelsnelheid structureel omlaag gaat. Ook de ontwikkelkwaliteit kan dalen. Dat is bijvoorbeeld merkbaar door het groeiend aantal bugs na een release of doordat problemen toch meerdere keren moeten worden opgelost. En kijk ook goed naar het werkplezier en de motivatie van het ontwikkelteam. Ook dit neemt vaak direct af zodra de tech debt groeit. Ook dat is een niet te onderschatten nadeel.

Als OutSystems partner bieden wij ontwikkelteams veel ondersteuning om technical debt te voorkomen. Maar daarnaast telt dus ook de werkwijze waar je samen voor kiest. In welke mate kies je daarin vooraf voor kwaliteit? Voor developers is het ook waardevol om nog eens oude code van henzelf te bekijken. Dat is soms confronterend. Waarom heb ik dat toen zo gedaan?! Het aantal ‘Hoe dan?!’ momenten per minuut zegt veel over de kwaliteit van de code. Naast dit bewustzijn tellen ook de omstandigheden waaronder een team moet functioneren. Welke rol speelt tijdsdruk en zijn er genoeg kwaliteitswaarborgen in het ontwikkelproces? Want uiteindelijk is bijna niets zo permanent als een tijdelijke oplossing.

Paul Schmeddes is OutSystems MVP (Most Valuable Professional) bij Synobsys, benoemd door onze partner. Een MVP is van grote waarde voor ontwikkelaars, klanten en andere gebruikers. Zijn aanwezigheid versterkt ons kwaliteitsstreven en onze inspanningen voor het opleiden en ontwikkelen van onze developers.