Wat is technische schuld (en heb je er te veel van?)
In het begin van mijn carrière als kersverse associate product manager, toen ik voor het eerst hoorde van technische schuld (ook wel technische schuld genoemd), wist ik niet helemaal zeker wat het betekende. Tot mijn grote hilariteit dacht ik dat het verwees naar een lening die we hadden afgesloten om software van derden aan te schaffen, en ik gebruikte deze term twee of drie weken lang vol vertrouwen verkeerd. Stel je mijn schaamte voor toen mijn softwareontwikkelaars me na de dagelijkse bijeenkomst even apart namen om me voorzichtig te corrigeren!
Dus, om ons allemaal wat blozende gezichten op het werk te besparen en ons te helpen geloofwaardigheid op te bouwen bij onze softwareontwikkelaars, gaan we eens dieper in op wat technische schuld is en waarom wij ons daar als productmanagers om zouden moeten bekommeren.
Wat is technische schuld en wanneer is het een probleem?
Softwareontwikkeling draait volledig om het vinden van een balans tussen de omvang van de productfunctionaliteit en code van hoge kwaliteit. Onderweg nemen we soms kortere routes om het ontwikkelproces te versnellen—deze kortere routes worden technische schuld of technische schuld genoemd.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Wanneer is het aangaan van technische schuld een goed idee, en wanneer wordt het een tikkende tijdbom? Om deze vraag te beantwoorden, kijken we eerst naar de geschiedenis van technische schuld.
Wat is technische schuld?
Ward Cunningham, de persoon die de term bedacht, vergelijkt technische schuld met financiële schuld—het is prima om te lenen ten koste van toekomstige snelheid en stabiliteit, maar uiteindelijk moeten we de schuld aflossen. Het is een concept dat elk ontwikkelingsteam zou moeten begrijpen en waar elke productmanager rekening mee zou moeten houden bij het nemen van productbeslissingen.
Technische schuld helpt ons om producten eerder dan gepland uit te brengen en zorgt ervoor dat producten sneller bij klanten terechtkomen. Maar uiteindelijk moeten we de schuld “afbouwen” door te investeren in de kwaliteit van onze codebasis.
Idealiter zouden we actief moeten beslissen of we technische schuld willen benutten of deze willen vermijden. Net als bij financiële schuld willen we later niet worden verrast door onverwachte kosten!
Een vereenvoudigde definitie van technische schuld
Technische schuld (in sommige teams ook wel codeschuld genoemd) verwijst naar de impliciete kosten van toekomstig herstelwerk die nodig zijn wanneer je voor een kortetermijnoplossing kiest in plaats van voor een betere aanpak die meer tijd zou kosten. Het is vergelijkbaar met het betalen van rente over een lening—de kosten van technische schuld nemen in de loop van de tijd toe.
Een vergelijking die ik gebruik, is het scheren van een baard. Als ik weinig tijd heb en me snel scheer, is dat waarschijnlijk niet de gladste scheerbeurt ooit en moet ik later terugkomen om het netjes af te werken.
De tijd en moeite die nodig zijn voor beide scheerbeurten—de eerste scheerbeurt en de tweede scheerbeurt om alles netjes af te werken—zullen in totaal meer zijn dan wanneer ik me meteen goed had geschoren.
Maar soms, wanneer we bijna geen tijd meer hebben, moeten we voor de snelle scheerbeurt kiezen!
Financiële schuld vergelijken met technische schuld
Om dit concept tot leven te brengen, gaan we wat dieper in op de vergelijking tussen financiële schuld en technische schuld. Productmanagers moeten immers zowel concepten uit de bedrijfsfinanciën als technische programmeerconcepten begrijpen!
Voordelen van financiële schuld: Financiële schuld maakt hefboomeffecten mogelijk. Geld lenen kan het kapitaal verschaffen dat nodig is om in groeimogelijkheden te investeren. Bovendien biedt financiële schuld direct toegang tot middelen of activa zonder dat vooraf betaling nodig is.
Nadelen van financiële schuld: Financiële schuld brengt veel verschillende soorten kosten met zich mee. Rentebetalingen over financiële schuld kunnen zich in de loop van de tijd opstapelen, waardoor de algehele winstgevendheid afneemt. Bovendien kan het niet goed beheren van financiële schuld leiden tot financiële instabiliteit.
Daarnaast kan schuld de financiële flexibiliteit beperken en ons ervan weerhouden om in de toekomst bepaalde richtingen in te slaan. En het niet nakomen van financiële verplichtingen kan de reputatie van een organisatie schaden.
Voordelen van technische schuld: Technische schuld maakt een snellere initiële productontwikkeling mogelijk, waardoor het gemakkelijker wordt om strakke deadlines te halen of marktkansen te benutten. En net als financiële hefboomwerking kan het aangaan van technische schuld de initiële ontwikkelingskosten verlagen.
Nadelen van technische schuld: Net zoals rente zich opstapelt bij financiële schuld, neemt technische schuld toe naarmate extra functies of wijzigingen worden gebouwd op basis van de bestaande kortere routes, waardoor toekomstige ontwikkeling complexer en duurder wordt. Bovendien leidt technische schuld vaak tot een suboptimale codekwaliteit, wat in de loop van de tijd tot hogere onderhoudskosten leidt.
Technische schuld kan het vermogen van een product belemmeren om zich aan veranderende marktomstandigheden aan te passen of nieuwe functies op te nemen. En onbeheerde technische schuld kan leiden tot systeemstoringen, beveiligingskwetsbaarheden of prestatieproblemen, waardoor de levensvatbaarheid van het product wordt aangetast.
Wat betekent dit voor ons? Wel, zowel bij financiële schuld als bij technische schuld is het doel niet om schuld volledig te vermijden. In plaats daarvan is zorgvuldig beheer de sleutel.
Hoewel een zekere mate van schuld strategisch kan zijn voor groei, moeten we schuld zorgvuldig monitoren en beheren om negatieve gevolgen op de lange termijn tot een minimum te beperken.
Voorbeelden van technische schuld
Op het gebied van softwareontwikkeling krijgen ontwikkelingsteams regelmatig te maken met technische schuld. Laten we enkele van de meest voorkomende voorbeelden bespreken.
Verouderde code
Sommige teams gebruiken mogelijk verouderde legacycode om snel een functie uit te brengen. Dit kan direct functionaliteit bieden, maar later aanzienlijke refactoring vereisen, vooral wanneer nieuwe functies worden toegevoegd. Net als een oud manuscript is legacycode van generatie op generatie door ontwikkelaars doorgegeven, waarbij het gewicht van de geschiedenis zich heeft opgestapeld.
Hoewel de code in zijn hoogtijdagen uitstekend dienst kan hebben gedaan, heeft tijd de neiging de aanpasbaarheid en onderhoudbaarheid ervan aan te tasten. Uitval en bugs in productie duiken vaak op wanneer we te veel op legacycode vertrouwen!
Hardcodering
Hardcodering verwijst naar het rechtstreeks opnemen van specifieke waarden of constanten in de code, in plaats van configureerbare instellingen te gebruiken.
Hoewel deze aanpak op korte termijn een snellere ontwikkeling kan opleveren, leidt deze vaak tot complicaties op de lange termijn. Stel je een situatie voor waarin een hardgecodeerde waarde, zoals een bestandspad of time-outdrempel, in een omvangrijke codebase moet worden gewijzigd. Dit kan snel een tijdrovende en foutgevoelige taak worden, waardoor de onderhoudbaarheid en flexibiliteit van de software in gevaar komen.
Om deze valkuil te vermijden, zouden ontwikkelaars moeten kiezen voor configureerbare opties, waarmee de aanpasbaarheid van hun code wordt vergroot.
Codeherhaling
Codeherhaling treedt op wanneer vergelijkbare of identieke codefragmenten op meerdere plaatsen binnen het project voorkomen. Aanvankelijk kan dit lijken op een handige snelkoppeling die tijd bespaart tijdens de ontwikkeling. Naarmate de software zich echter ontwikkelt en vereisten veranderen, worden consistentie behouden en updates uitvoeren een ingewikkelde dans.
Codeherhaling vergroot niet alleen het risico op het introduceren van bugs, maar vermenigvuldigt ook de inspanning die nodig is voor toekomstige verbeteringen en bugfixes. Het streven naar herbruikbaarheid van code en het elimineren van overbodige code zijn fundamentele principes om dit probleem tegen te gaan.
Gebrek aan documentatie
Documentatie dient als de leidende draad die het pad verlicht voor huidige en toekomstige ontwikkelaars. Het ontbreken van uitgebreide documentatie is vergelijkbaar met het beginnen aan een complexe reis zonder kaart. Het kan beginnen met een gebrek aan inlineopmerkingen waarin de reden achter bepaalde codekeuzes wordt uitgelegd, of escaleren tot ontbrekende gebruikershandleidingen en documentatie van de systeemarchitectuur.
Hoewel de eerste ontwikkelingsfase soepel kan verlopen, kunnen de gevolgen op lange termijn ernstig zijn. Debuggen wordt een cryptische onderneming, kennisoverdracht tussen teamleden wordt lastig en het opschalen van het project lijkt vaak op het navigeren door een doolhof in het donker. Grondige documentatie omarmen is het baken dat de weg vooruit verlicht in softwareontwikkeling.
Gebrek aan geautomatiseerde tests
Het ontbreken van geautomatiseerde tests is vergelijkbaar met varen in een boot zonder eerst te controleren of deze lekken heeft. Geautomatiseerde tests (waaronder unittests, integratietests en regressietests) zijn de waakzame bewakers van codekwaliteit en stabiliteit.
Wanneer deze tests worden weggelaten, zijn de gevolgen mogelijk niet direct zichtbaar. Aanvankelijk kan de ontwikkeling snel verlopen en kan de software functioneel lijken. Naarmate de codebase echter groeit en evolueert, beginnen onvoorziene problemen aan het licht te komen. Regressiebugs, waarbij eerder werkende functies breken door nieuwe wijzigingen, worden alledaags.
Zonder geautomatiseerde tests als vangnet moet het ontwikkelingsteam vertrouwen op handmatig testen, een tijdrovend en foutgevoelig proces. Door vanaf het begin geautomatiseerd testen toe te passen, blijft de koers stabiel op de woelige zee van softwareontwikkeling.
Welke rol speelt technische schuld in Agile?
Ah, Agile-ontwikkeling! De scrum-methodologieën en principes ervan uit het Agile-manifest omarmen verandering en snelheid. Maar waar past technische schuld hierin? Technische schuld wordt immers niet specifiek besproken in de oprichtingsdocumenten van Agile.
Welnu, hier is een analogie uit Star Wars: de Millennium Falcon werd voortdurend onderhouden door Han Solo en Chewbacca om in topconditie te blijven voor hun avonturen. Op dezelfde manier beheert een Agile-productteam technische schuld om de softwarekwaliteit te behouden en heroïsche avonturen voor hun klanten mogelijk te maken!
Technische schuld gebruiken en beheren
Binnen Agile-teams bestaat het besef dat je soms technische schuld opbouwt om snel aan zakelijke behoeften te voldoen. Onthoud dat het opbouwen hiervan niet altijd slecht is. Martin Fowler, een invloedrijke denker op het gebied van Agile-softwareontwikkeling, wijst erop dat het om afwegingen gaat. Je kunt in een vroeg stadium van de levenscyclus van een softwareproduct enige schuld accepteren om een concept te valideren of sneller de markt te bereiken.
De sleutel is het beheren van technische schuld. Technische schuld moet in de backlog worden gedocumenteerd, worden geprioriteerd en in toekomstige sprints worden aangepakt. Om dit mogelijk te maken, moeten productmanagers steunen op sterk projectmanagement en een goed inzicht hebben in de hoeveelheid technische schuld die tot nu toe is opgebouwd.
Wanneer is technische schuld een probleem?
Wanneer belanghebbenden zich niet bewust zijn van technische schuld of wanneer het ontwikkelingsproces sterk afhankelijk is van tijdelijke oplossingen, zouden de alarmbellen moeten gaan rinkelen. Waarom?
- Het is onzichtbaar: Zonder statistieken of regelmatige codebeoordelingen kunnen verborgen kwetsbaarheden ontstaan.
- Het beïnvloedt de gebruikerservaring: Als onderliggende problemen de functionaliteit beginnen te beïnvloeden, is het niet alleen een probleem voor ontwikkelaars; het is een bedrijfsprobleem.
- Het belemmert nieuwe functies: Programmeurs die vastzitten in slechte code zijn minder productief en hun creativiteit neemt af.
- Het staat niet op de routekaart: Teams moeten zich bewust zijn van technische schuld en er een strategie voor hebben. Aarzel niet om gebruik te maken van externe webinars en bronnen om een plan van aanpak op te stellen.
Hoe meet je technische schuld?
Met behulp van tools zoals DevOps-praktijken en automatisering kunnen teams hun codebasis in de gaten houden en zicht houden op de technische schuld die tot nu toe is opgebouwd. Hieronder heb ik twaalf verschillende manieren verzameld waarop je technische schuld kunt volgen.
Je hoeft ze niet allemaal te gebruiken! Zie deze lijst in plaats daarvan als een startpunt. Kies er een of twee om de komende maand ongeveer te implementeren en bouw vervolgens geleidelijk de expertise van je team op in het volgen en oplossen van technische schuld.
1) Statische codeanalyse: Tools zoals SonarQube, ESLint of FindBugs kunnen code automatisch analyseren op verschillende problemen, zoals codecomplexiteit, codegeuren en mogelijke bugs. Ze leveren kwantitatieve statistieken over codekwaliteit en technische schuld op basis van vooraf gedefinieerde regels en drempelwaarden.
2) Codetestdekking: We kunnen beoordelen welk deel van de codebasis wordt gedekt door geautomatiseerde tests door de testdekking te meten met tools zoals JaCoCo of Istanbul. Een lage code-testdekking kan wijzen op een gebrek aan tests en mogelijke technische schuld.
3) Collegiale codebeoordelingen: Door collegiale codebeoordelingen uit te voeren, kunnen ontwikkelaars mogelijke onderdelen van technische schuld identificeren en bespreken. En twee weten meer dan één: het is een geweldige manier om slechte codepatronen te voorkomen! Teams kunnen checklists of richtlijnen gebruiken om de codekwaliteit te beoordelen en geïdentificeerde problemen te documenteren. Het aantal en de ernst van de problemen die tijdens beoordelingen worden gevonden, kunnen dienen als een kwalitatieve maatstaf voor technische schuld.
4) Handmatige code-inspecties: Ontwikkelaars en teams kunnen handmatige code-inspecties of stapsgewijze doorlopen uitvoeren om delen van de codebasis te identificeren die baat kunnen hebben bij refactoring. Bij dit proces beoordelen ervaren ontwikkelaars vaak de code en documenteren zij problemen, omdat zij doorgaans het beste inzicht hebben in technische ontwerpschuld.
5) Achterstand voor technische schuld: Het bijhouden van een productbacklog of lijst met geïdentificeerde onderdelen van technische schuld is een veelgebruikte praktijk. Elk item in de backlog moet een beschrijving, impactbeoordeling en prioriteitsbeoordeling bevatten. De omvang en prioriteit van de items in de backlog bieden een kwalitatieve maatstaf voor technische schuld.
6) Fouten- en probleemregistratie: Het analyseren van het proces voor het prioriteren van bugs kan de frequentie en ernst van problemen die verband houden met technische schuld aan het licht brengen. Grote aantallen bugmeldingen of het regelmatig terugkeren van dezelfde problemen kunnen wijzen op onderliggende technische schuld.
7) Schattingen en story points: Bij het plannen van nieuw werk of gebruikersverhalen kunnen ontwikkelingsteams een schatting maken van de inspanning die nodig is om onderdelen van technische schuld aan te pakken. Deze inspanninginschatting, vaak uitgedrukt in story points binnen Agile-methodologieën, kwantificeert het werk dat nodig is om technische schuld op te lossen.
8) Maatstaven voor codecomplexiteit: Maatstaven zoals cyclomatische complexiteit, het aantal regels code en codewijzigingen kunnen inzicht bieden in de complexiteit en onderhoudbaarheid van de codebasis. Een hogere complexiteit en buitensporige wijzigingen in bepaalde delen van de code kunnen wijzen op technische schuld.
9) Feedback van gebruikers: Feedback van gebruikers en ondersteuningsverzoeken kunnen indirect technische schuld aan het licht brengen. Veelvuldige klachten van gebruikers over systeemprestaties, betrouwbaarheid of onverwacht gedrag kunnen wijzen op onderliggende problemen die moeten worden aangepakt.
10) Maatstaven voor geautomatiseerd testen: Het monitoren van statistieken met betrekking tot geautomatiseerd testen, zoals de uitvoeringsduur van tests, het percentage mislukte tests en instabiele tests, kan helpen de gezondheid van de testinfrastructuur te beoordelen en gebieden te identificeren die door technische schuld worden beïnvloed.
11) Enquêtes en interviews: Het houden van enquêtes en interviews met ontwikkelingsteams kan kwalitatief inzicht bieden in het waargenomen niveau van technische schuld en de impact ervan op productiviteit en codekwaliteit. Daarnaast kan het verzamelen van feedback van belanghebbenden inzicht geven in waar herwerk nodig kan zijn.
12) Kwadrant voor technische schuld: Een bijzonder nuttige tool is het kwadrant voor technische schuld dat door Martin Fowler is geïntroduceerd. Het categoriseert de oorzaken van technische schuld als opzettelijk versus onopzettelijk en roekeloos versus weloverwogen, waardoor teams afwegingen beter kunnen begrijpen.
Naast deze twaalf manieren om technische schuld te meten, kun je gerust productmanagementtools gebruiken om het bijhouden en oplossen van de technische schuld van je team te ondersteunen!
Technische schuld aflossen
We hebben veel gesproken over het opbouwen van technische schuld, maar we hebben nog niet besproken hoe je deze aflost. Als productmanagers is het onze verantwoordelijkheid om onze teams te begeleiden bij de beslissing wanneer ze de schuld moeten aflossen en wanneer ze aanvullende technische schuld kunnen opbouwen.
We lossen technische schuld af wanneer ingenieurs de codebasis bijwerken om eerder geïdentificeerde onderdelen van technische schuld aan te pakken. Dit kan bestaan uit het herontwerpen van functionaliteit om deze efficiënter te maken, het implementeren van geautomatiseerde tests of het verstrekken van uitgebreide documentatie over de code.
Een van de beste manieren om deze schuld af te bouwen, is door in elke sprint tijd vrij te houden voor het versterken van de codebasis en het aflossen van de schuld. Zie dit als het doen van maandelijkse hypotheekbetalingen: hoe sneller we de hypotheek kunnen aflossen, hoe minder rente we uiteindelijk hoeven te betalen!
Een goede vuistregel is de 80/20-regel. Besteed dus ongeveer 80% van de tijd in elke sprint aan het bouwen van nieuwe functies en 20% van de tijd aan het prioriteren van technische investeringen en verbeteringen.
Als je van plan bent technische schuld af te bouwen, overweeg dan om deze dienovereenkomstig op te nemen in je productroutekaart.
Slotgedachten over technische schuld
Samenvattend: het beheren van technische schuld is niet alleen een taak voor ontwikkelaars. Productmanagers, Agile-teams en zakelijke belanghebbenden spelen allemaal een rol.
Het uiteindelijke doel? Een softwareproduct van hoge kwaliteit leveren dat aan de bedrijfsdoelstellingen voldoet zonder onhoudbare schuld op te bouwen.
Dus of je nu de diepe zeeën van softwareontwikkeling induikt of gewoon probeert te begrijpen waarom je ontwikkelingsteam het steeds heeft over het herstructureren van code, inzicht in en het beheren van technische schuld is het kompas dat je nodig hebt.
En of je nu aan het begin van je productcarrière staat of al een doorgewinterde professional in productmanagement bent, je hebt vrijwel altijd baat bij een beter begrip van technische terminologie.
Ik hoop dat je niet dezelfde fout maakt als ik aan het begin van mijn carrière: vertrouw niet uitsluitend op contextuele aanwijzingen om onbekende technische concepten te raden!
Neem in plaats daarvan de tijd om onderzoek te doen, externe handleidingen zoals deze te raadplegen en tijd met je ingenieurs door te brengen om waardevolle kennis op te frissen.
Voor meer inzichten en handleidingen over productmanagement: vergeet je niet te abonneren op onze nieuwsbrief!
