Wat is technische schuld? Hoe je het afbetaalt (met voorbeelden)

Werken in de productruimte vereist vaak snelle beslissingen over softwarefuncties. Als je ooit in een DevOps-team hebt gewerkt, weet je hoeveel beslissingen er nodig zijn om functies live te zetten. Deze keuzes kunnen van invloed zijn op de codebase, gebruikerservaring, time-to-market en meer.

Technische schuld is de term die wordt gebruikt om het resultaat te beschrijven van het nemen van beslissingen op basis van snelheid boven alles. Deze snelle, realtime beslissingen kunnen software-updates maken of breken. Maar er moet een evenwicht zijn tussen goede beslissingen en snelle beslissingen. Het oplopen van technische schuld kan leiden tot negatieve resultaten of het kan de moeite waard zijn, afhankelijk van wat jij en je Team besluiten. Het is niet altijd een slechte zaak, maar te veel schuld vermindert de onderhoudbaarheid en de kwaliteit van de code.

In dit artikel bespreken we de definitie van technische schuld, hoe je snel beslissingen in het ontwikkelingsproces effectief kunt beheren en delen we voorbeelden om je een beter inzicht te geven in hoe je toekomstige misstappen kunt voorkomen. We behandelen onderwerpen zoals refactoring, automatisering, statistieken, codebeoordelingen en afstemming op de behoeften van het bedrijf.

Wat is technische schuld?

Technische schuld is de prijs van extra herwerkingen als gevolg van het selecteren van de snelste oplossing in plaats van de meest efficiënte. Softwareontwikkelaar Ward Cunningham gebruikte de uitdrukking voor het eerst in 1992, maar sindsdien is het geëvolueerd.

Tegenwoordig treedt technische schuld, ook wel bekend als tech debt en code debt, meestal op wanneer ontwikkelingsteams ervoor kiezen om snelle code te schrijven tijdens het bouwen van nieuwe functies van een softwareontwikkelingsproduct. Snelle codelevering kan je team helpen deadlines te halen en de schuld die je opbouwt is het misschien waard, maar het kan ook leiden tot negatieve resultaten als het verkeerd wordt beheerd. Deze negatieve resultaten zijn niet altijd te vermijden zodra de beslissing om technische schuld op te bouwen is genomen. 

Of je nu een goede of slechte uitkomst ervaart, we bespreken de belangrijke feiten over technische schuld, zodat je voorbereid bent om op het juiste moment de juiste beslissingen te nemen.

Geen silo's meer: je organisatiestructuur optimaliseren voor een sterkere samenwerking tussen teams

In dit e-book leert je hoe je je organisatie structureert om silo's te voorkomen, sneller te handelen en op één lijn te blijven met het oog op veranderingen.

Krijg de inzichten

Is technische schuld slecht?

Net als financiële schuld kan technische schuld zowel op goede als slechte manieren worden gebruikt.

In sommige gevallen is technische schuld het resultaat van een berekende zet om zowel deadlines voor software te halen als code van hoge kwaliteit binnen sprints te verzenden. In andere gevallen is technische schuld het gevolg van een onvermijdelijke fout bij het uitbrengen van een software-update.

Wat veroorzaakt technische schuld?

Er zijn vier verschillende oorzaken van technische schuld, de zogenaamde technische schuldkwadranten. De vier kwadranten van technische schuld, bedacht door Martin Fowler, omvatten roekeloos, voorzichtig, opzettelijk en onbedoeld. Deze kwadranten helpen teamleden en belanghebbenden de verschillende soorten schuld te begrijpen die zich in de codebase kunnen ophopen.

Het toewijzen van technische schuld aan deze vier kwadranten helpt bij het meten van de intentie en achtergrond van codeproblemen. Hoewel sommige codeschuld opzettelijk kan zijn en als goede schuld kan worden geclassificeerd, kan andere schuld, zoals snelle oplossingen en slechte code, onbedoeld zijn en als slechte schuld worden geclassificeerd.

1. Voorzichtig en weloverwogen: de beslissing om snel te verzenden en de gevolgen later af te handelen, veroorzaakt voorzichtige en weloverwogen schuld. Dit type schuld wordt meestal gebruikt wanneer de inzet in het softwareproject relatief laag is en de voordelen van een snelle levering opwegen tegen het risico. Het is een bewuste afweging om de time-to-market te verbeteren.

2. Roekeloos en weloverwogen: Weten hoe je de beste code kunt produceren, maar prioriteit geven aan snelle levering is de oorzaak van roekeloze en weloverwogen schuld. Dit leidt vaak tot legacy code die moeilijker te onderhouden is. 

3. Voorzichtig en onbedoeld: Voorzichtige en onbedoelde schuld ontstaat wanneer er een wens is om de beste code te produceren, maar je na de implementatie een betere oplossing vindt. Geautomatiseerde tests en andere methodologieën kunnen helpen om dit eerder op te merken.

4. Roekeloos en onbedoeld: Roekeloze en onbedoelde schuld treedt op wanneer een team probeert de beste code te produceren zonder de nodige kennis om dit te doen. Het team is zich vaak niet bewust van de fouten die ze maken. Dit kan kwetsbaarheden en onderhoudsproblemen veroorzaken.

Teams kiezen voor opzettelijke technische schuld om snel te kunnen leveren, terwijl onbedoelde schuld per ongeluk is - het gebeurt na de implementatie. Dit verschil wordt het best beschreven door software-engineer Steve McConnell bij het beschrijven van de twee algemene soorten technische schuld. Het begrijpen van deze kwadranten is de sleutel tot het beheren van schuld in ontwikkelingscycli. Laten we elk van deze onderzoeken om een beter begrip te krijgen.  

Soorten technische schuld

Steve McConnell, Chief Software Engineer bij Construx Software, suggereerde dat er twee soorten technische schuld zijn: opzettelijk en onopzettelijk.

1. Opzettelijke technische schuld

Opzettelijke schuld treedt op wanneer een organisatie een bewuste beslissing neemt om te optimaliseren voor het heden in plaats van voor de toekomst. Bedrijfsbehoeften en druk van belanghebbenden zoals productmanagers en CIO's om snel functies te leveren, zijn vaak de drijvende krachten hierachter.

Er zijn zowel kortetermijn- als langetermijnvariaties van opzettelijke schuld. Opzettelijke schuld die is opgebouwd om een eerdere ontwerpschuld af te lossen, is bijvoorbeeld kortetermijnschuld, terwijl een opzettelijke schuld die is opgebouwd om een grotere toekomstige documentatieschuld te voorkomen, een langetermijnschuld zou zijn. 

• Kortetermijnschuld: Kortetermijnschuld wordt reactief gemaakt, om tactische redenen zoals het gebruik van bestaande middelen. Bovendien kan kortetermijnschuld gericht of ongericht zijn. Teamleden kunnen kortetermijnschulden aangaan om snel bugfixes of andere verbeteringen aan de gebruikerservaring te leveren.

• Gerichte kortetermijnschuld: dit omvat individueel identificeerbare snelkoppelingen. 

• Ongefocuste kortetermijnschuld: dit omvat tal van kleine snelkoppelingen. Na verloop van tijd kan dit de ontwikkelingscycli echt vertragen.

• Langetermijnschuld: Langetermijnschuld wordt proactief gemaakt, om strategische redenen zoals het halen van een deadline. Inzet voor automatisering en refactoring vallen vaak in deze categorie.

Zoals je kunt zien, bepaalt het soort schuld dat is opgebouwd hoe lang het duurt om deze af te betalen.

2. Onbedoelde technische schuld

Onbedoelde technische schuld daarentegen ontstaat door een gebrek aan begrip, onbedoelde fouten of, in sommige gevallen, slecht geschreven code. Een voorbeeld van onbedoelde technische schuld is een ontwerpbenadering die foutgevoelig blijkt te zijn. Regelmatige codebeoordelingen kunnen helpen om deze problemen eerder op te sporen.

We kunnen aannemen dat onbedoelde technische schuld per ongeluk is, omdat het team deze niet expres heeft gemaakt. Meestal zul je je fout pas beseffen nadat je de software-update hebt geïmplementeerd of het project hebt voltooid. 

Hoe meet je technische schuld

Het meten van technische schuld is noodzakelijk voor softwareontwikkelingsteams om de omvang van hun codeschuld te begrijpen en weloverwogen beslissingen te nemen over het beheer ervan. Door technische schuld te kwantificeren, kunnen teams prioriteit geven aan refactoring-inspanningen en ervoor zorgen dat hun codebase op de lange termijn onderhoudbaar en schaalbaar blijft.

Statistieken en tools

Verschillende statistieken kunnen worden gebruikt om de hoeveelheid technische schuld in een softwareproject te beoordelen. Deze omvatten codecomplexiteit, duplicatie, testdekking en onderhoudbaarheidsindexen. Tools zoals SonarQube, CAST en Kiuwan kunnen het meetproces automatiseren en waardevolle inzichten bieden in de gezondheid van je codebase.

Beste praktijken voor beoordeling

Bij het beoordelen van technische schuld is het essentieel om alle belanghebbenden te betrekken, inclusief ontwikkelaars, productmanagers en bedrijfsleiders. Regelmatige codebeoordelingen en discussies over de schuldmetafoor kunnen helpen om het bewustzijn te vergroten en een gedeeld begrip van de impact van technische schuld te bevorderen. Het prioriteren van schuld op basis van het vermogen om ontwikkelingscycli, functionaliteit en gebruikerservaring te belemmeren, is de sleutel tot een effectieve beoordeling.

Hoe betaal je technische schuld af

Hoewel je misschien opzettelijk wat technische schuld opbouwt, hebben veel productteams moeite om technische schuld bij te houden en te communiceren. Dit kan resulteren in meer werk dan verwacht bij het oplossen van de hiaten in softwarecode. 

Deze stapsgewijze handleiding helpt je technische schulden af te lossen en zorgt voor meer transparantie op de werkplaats rondom de schuldenlast. 

Stap 1: Identificeer en prioriteer je technische schuld 

De eerste stap bij het aflossen van technische schuld is het identificeren en prioriteren van de gebieden van je codebase die aandacht nodig hebben. Dit omvat het analyseren van statistieken, het uitvoeren van codebeoordelingen en het verzamelen van input van teamleden. Geef prioriteit aan schulden op basis van de impact op functionaliteit, onderhoudbaarheid en bedrijfsbehoeften.

• Houd een schuldenlijst bij in een volgsysteem. Elke keer dat je schuld maakt, voer je de taken in die nodig zijn om die schuld af te betalen in je trackingsysteem, samen met een geschatte inzet en planning. Gebruik de schuldenbacklog om de voortgang van je technische schuld bij te houden. Elke onopgeloste schuld die ouder is dan 90 dagen moet als kritiek worden behandeld.

• Als je Scrum gebruikt, houd dan de schuldenlijst bij als onderdeel van je Scrum Product-backlog, behandel elke schuld als een Scrum-'story' en schat de inzet en planning om elke schuld af te lossen - op dezelfde manier als je andere stories in Scrum schat.

Stap 2: Refactor en optimaliseer je code

Zodra je de technische schuld met hoge prioriteit hebt geïdentificeerd, is het tijd om te beginnen met het refactoren en optimaliseren van je code. Dit kan inhouden dat complexe functies worden afgebroken, duplicatie wordt geëlimineerd, naamgevingsconventies worden verbeterd en verouderde raamwerken worden bijgewerkt. Vermijd snelkoppelingen en snelle oplossingen, omdat deze op de lange termijn tot meer schuld kunnen leiden.

Stap 3: Stel coderingsnormen en beste praktijken vast

Om de ophoping van nieuwe technische schulden te voorkomen, moet je duidelijke coderingsnormen en beste praktijken voor je ontwikkelteam vaststellen. Dit omvat richtlijnen voor codestructuur, commentaar, testen en documentatie. Moedig teamleden aan om deze normen consequent te volgen en bied indien nodig training en ondersteuning.

Stap 4: Houd nieuwe schulden voortdurend in de gaten en pak ze aan

Technische schuld is een voortdurende zorg en het is essentieel om nieuwe schuld voortdurend te monitoren en aan te pakken wanneer deze zich voordoet. Beoordeel je codebase regelmatig met behulp van statistieken en tools en neem schuldbeheer op in je ontwikkelingsproces. Overweeg om methodologieën zoals Scrum of DevOps te gebruiken om continue verbetering en schuldvermindering te ondersteunen. 

Voorbeelden en oplossingen voor technische schuld

Nu je begrijpt hoe je technische schuld beheert en enkele oorzaken achter onbedoelde en opzettelijke schuld kent, laten we enkele voorbeelden uit de praktijk bekijken. 

Voorbeeld 1: Opzettelijke technische schuld

• Beschrijving: Het team kiest een raamwerk dat snel te bouwen is, bekende prestatieproblemen heeft en minimale functionaliteitsmogelijkheden heeft.

• Oplossing: Het team gebruikt aanvullende applicaties voor post-software-implementatie die de ontbrekende raamwerkfunctionaliteit bevatten.

• Schuld: Hoewel ze de productdeadline hebben gehaald, zal het team de functies na de lancering moeten herwerken en extra geld nodig hebben.  

Voorbeeld 2: Onbedoelde technische schuld

• Beschrijving: Het team heeft veel junior ontwikkelaars die helpen bij het lanceren van een nieuwe softwarefunctie met een krappe deadline, met niet genoeg senior ontwikkelaars om elk stukje code te beoordelen. 

• Oplossing: Het team huurt extra tijdelijke ondersteuning in van senior ontwikkelaars om de code te bekijken en te controleren op de juiste functionaliteit. 

• Schuld: Hoewel het team de meeste problemen heeft opgelost, heeft de miscommunicatie tussen fulltime personeel en tijdelijke ondersteuning ertoe geleid dat sommige gemiste bugs in de code over het hoofd zijn gezien. Dit betekent dat het team deze problemen na de lancering moet debuggen. 

Zoals je kunt zien, moeten zowel opzettelijke als onopzettelijke schulden in de loop van de tijd worden afbetaald. Door te brainstormen over een oplossing voor technische schuld, kun je ervoor zorgen dat je software-updates op tijd worden gelanceerd met weinig opgebouwde schuld. 

Beheer je technische schuld met transparantie

Schuld is niet altijd te vermijden wanneer je aan een softwareproductlancering werkt. Van moeilijke beslissingen tot fouten in code, Agile-teams weten hoe de hoeveelheid opgebouwde technische schuld software-updates kan beïnvloeden. 

De sleutel tot het aflossen van schulden is het onderhouden en bijhouden van incrementele betalingen. Hoewel het type aflossing in elk scenario anders is, kunnen teamtransparantie en communicatie je helpen je schuld sneller af te lossen. Dit komt omdat meer helderheid over Agile-projecten kan zorgen voor een collectieve oplossing voor het probleem.

Geen silo's meer: je organisatiestructuur optimaliseren voor een sterkere samenwerking tussen teams

In dit e-book leert je hoe je je organisatie structureert om silo's te voorkomen, sneller te handelen en op één lijn te blijven met het oog op veranderingen.

Krijg de inzichten

Veelgestelde vragen: technische schuld

Wat is technische schuld in Scrum?

In Scrum verwijst technische schuld naar de opeenstapeling van werk dat moet worden gedaan om de kwaliteit van het softwareproduct te behouden en te verbeteren. Het ontstaat wanneer het ontwikkelingsteam bewuste beslissingen neemt om snelheid boven kwaliteit te stellen of wanneer ze onbewust schulden maken vanwege een gebrek aan ervaring of kennis. In Scrum wordt technische schuld vaak weergegeven als backlog-items die in toekomstige sprints moeten worden aangepakt.

Is technische schuld goed of slecht?

Technische schuld is niet inherent goed of slecht; het hangt af van hoe het wordt beheerd. In sommige gevallen kan het aangaan van technische schuld een strategische beslissing zijn waarmee het team sneller waarde kan leveren. Als je er echter niets aan doet, kan technische schuld leiden tot hogere onderhoudskosten, lagere productiviteit en zelfs het mislukken van een project. Daarom is het cruciaal om een evenwicht te vinden tussen het maken en aflossen van technische schulden.

Wat zijn de meest voorkomende oorzaken van technische schuld?

Veelvoorkomende oorzaken van technische schuld zijn strakke deadlines die het team dwingen om snelkoppelingen te nemen, een gebrek aan coderingsnormen en beste praktijken, onvoldoende testen en documentatie, en het gebruik van verouderde of incompatibele technologieën. Andere factoren, zoals teamverloop en gebrek aan communicatie, kunnen ook bijdragen aan de opbouw van technische schuld.

Hoe kan technische schuld een project beïnvloeden?

Technische schuld kan een aanzienlijke impact hebben op het succes van een project. Naarmate de hoeveelheid schuld toeneemt, wordt de codebase complexer en moeilijker te onderhouden, wat leidt tot langere ontwikkelingscycli en meer bugfixes. Dit kan op zijn beurt de levering van nieuwe functies vertragen en de gebruikerservaring negatief beïnvloeden. In extreme gevallen kan technische schuld een project onhaalbaar maken, waardoor de codebase volledig opnieuw moet worden geschreven.

Hoe kan technische schuld worden voorkomen?

Het voorkomen van technische schuld vereist een proactieve aanpak waarbij het hele ontwikkelingsteam betrokken is. Dit omvat het vaststellen en naleven van coderingsnormen en beste praktijken, het uitvoeren van regelmatige codebeoordelingen en het prioriteren van testen en documentatie. Agile-methodologieën, zoals Scrum, kunnen ook helpen technische schuld te voorkomen door frequente feedback en continue verbetering aan te moedigen. Bovendien kan het toewijzen van tijd in elke sprint om technische schuld aan te pakken helpen om deze onder controle te houden.