Request your demo of the Sigrid® | Software Assurance Platform:
Hoewel technical debt in vrijwel ieder softwaresysteem voorkomt, is het voor veel mensen nog een beetje een ongrijpbaar begrip. Want wat is technical debt nu eigenlijk, en kun je wel voorkomen dat het in je systemen terecht komt? AG Connect zocht het aan de hand van zes vragen uit.
De term ‘technical debt’ werd in 1992 voor het eerst gebruikt door Ward Cunningham om een vergelijking te maken tussen technische complexiteit en een geldschuld. Als je geld leent, heb je op de korte termijn een voordeel, namelijk meer geld. Maar uiteindelijk moet je het bedrag terug gaan betalen, vaak met rente.
Bij technical debt gebeurt ongeveer hetzelfde. Je voert een technische implementatie door of maakt een ontwerp dat je op de korte termijn iets oplevert, zoals een tijdbesparing. Maar op de lange termijn zorgt die implementatie voor vertraging als je de code aan wil passen of iets nieuws toe wil voegen.
“De metafoor is vooral bedoeld om te laten zien dat software ook kwaliteit heeft, en dat het wat kost als die kwaliteit slecht is. Je kunt niet aan programmeurs blijven vragen om iets binnen vijf uur te maken, want dan gaat de kwaliteit achteruit en kost het je uiteindelijk meer tijd en geld om iets toe te voegen”, vertelt Jurgen Vinju, leider van de onderzoeksgroep Software Analysis and Transformation (SWAT) bij het Centrum Wiskunde & Informatica (CWI) en part-time professor aan de Technische Universiteit Eindhoven.
Gelukkig kun je technical debt ook weer inlossen: je kunt de schuld afbetalen door de tijd te nemen om de implementatie alsnog op de nette en optimale manier in de code te plaatsen.
Als je te maken hebt met technical debt, heb je vrijwel altijd te maken met een stuk code die niet op de beste manier geschreven of geïmplementeerd is. “Er zijn zeer veel verschillende manieren om iets toe te voegen of aan te passen aan software, maar slechts een paar daarvan zijn kwalitatief hoogwaardig. Er wordt niet altijd voor die oplossingen gekozen”, vertelt Werner Heijstek, principal consultant bij de Software Improvement Group (SIG) en docent aan het Leiden Institute for Advanced Computer Science (LIACS).
Volgens Vinju heeft het te maken met in hoeverre er nagedacht is over toekomstige veranderingen. “Als ik nu al weet dat de kans bestaat dat iemand over vijf jaar een ander databasesysteem gaat gebruiken, dan zorg ik er nu al voor dat de huidige database zo los mogelijk aan het softwaresysteem hangt”, legt Vinju uit. “Maar als je een slechte inschatting maakt of geen tijd hebt om die inschatting te maken, dan maak je een koppeling die moeilijk is om weer los te koppelen en waar steeds meer afhankelijk van wordt. Over een paar jaar kost het dan veel meer moeite om het databasesysteem weer los te koppelen dan nodig was geweest.”
Maar er is ook technical debt die per ongeluk ontstaat. “Je kunt het opdelen in twee categorieën: opzettelijke technical debt en onopzettelijke technical debt”, licht Heijstek toe. Bij de opzettelijke variant wordt er een bewuste keuze gemaakt om technical debt te maken, bijvoorbeeld om tijd te besparen bij een project waarvan de deadline snel nadert. Bij onopzettelijke technical debt is er iets anders aan de hand. Je kunt bijvoorbeeld te maken hebben met ontwikkelaars die bepaalde vaardigheden missen, waardoor een probleem niet op de beste manier wordt opgelost.”
Nee, technical debt is echt iets anders dan een fout of een bug in de code. “Een fout zegt iets over het gedrag van software. Je ziet dat de software dan iets doet wat het niet moet doen”, legt Heijstek uit. “Technical debt gaat over de interne kwaliteit, over de manier waarop software is gemaakt. Het is eigenlijk een optelsom van alles wat je tegenhoudt om optimaal te kunnen werken aan een softwaresysteem.”
Technical debt is dus niet per se een fout of bug: de applicatie kan precies doen wat het moet doen, zelfs al is er technical debt aanwezig. Een dergelijke schuld kan echter wel leiden tot fouten in een programma. Als het lastig is om iets aan te passen, kan het immers voorkomen dat je per ongeluk iets kapot maakt.
Cunningham besprak de problemen die technical debt kan veroorzaken al toen hij zijn vergelijking voor het eerst beschreef. “Een beetje schuld versnelt de ontwikkeling, mits het snel terugbetaald wordt met refactoring. Het gevaar ontstaat als de schuld niet terugbetaald wordt. Iedere minuut die aan code die niet optimaal is voor de programmeertaak van dat moment besteed wordt, geldt als rente op die schuld.”
Technical debt leidt namelijk tot een slechtere onderhoudbaarheid van software. “Het kost bijvoorbeeld meer geld om een wijziging aan te brengen in een systeem of je hebt acht van je tien ontwikkelaars nodig om te zorgen dat het systeem onderhouden wordt en blijft werken”, aldus Heijstek. Wordt de code bovendien niet snel verbeterd, dan vergeet je hoe en waarom je iets ook alweer gedaan had. Hoe langer je wacht, hoe meer tijd het dus kost om de schuld weer af te lossen.
De slechtere onderhoudbaarheid van het systeem zorgt er ook voor dat het langer kan duren voor een fout opgelost is. Als het systeem niet goed te onderhouden is, duurt het immers langer voor het precieze probleem bij een fout gevonden is en om de code zo aan te passen dat het probleem opgelost wordt. Bovendien kan een systeem uiteindelijk zoveel technical debt krijgen dat het niet meer aangepast kan worden en het out-of-service gaat.
Een ander gevolg kan bovendien zijn dat vrijwel niemand nog begrijpt hoe het systeem precies werkt, vertelt Vinju. “Het is dan voor nieuwer personeel lastiger om dit te leren. Dus als ouder personeel dat nog wel begrijpt hoe het systeem werkt uiteindelijk weggaat, weet niemand meer hoe het systeem werkt. Het heeft dus ook effect op je personeelsbeleid: je zit vast aan de mensen die wél begrijpen hoe het werkt.”
Technical debt kan tot op zekere hoogte voorkomen worden. Volgens Heijstek is helpt het bijvoorbeeld als er heldere en centrale regels zijn over hoe er met de ontwikkeling van software om moet worden gegaan en wat er precies verwacht wordt. “Het is veel goedkoper om direct code te schrijven die goed onderhoudbaar is, dan om code te schrijven met veel technical debt”, stelt Heijstek.
Bovendien is vaak niet helemaal duidelijk wát goede softwarekwaliteit dan precies is. “Wat goed of slecht is hangt heel erg af van het publiek”, verklaart Vinju. “Wat voor de één hoge kwaliteit is, is voor de ander juist lage kwaliteit. Dat heeft onder meer te maken met aan welke programmeertalen je gewend bent, welke lososche paradigma’s je gebruikt en welke opleiding je gedaan hebt. Er is niet één universele, objectieve maat voor wat goed en slecht is.”
Heijstek nuanceert Vinju’s stelling door toe te voegen dat kwaliteit wel degelijk universeel meetbaar is. “Verschillende systemen kunnen zeker met een objectieve maat met elkaar vergeleken worden.” Daarnaast zijn er tools die je kunnen ondersteunen, vertellen zowel Vinju als Heijstek. Die tools geven bijvoorbeeld aan hoe goed het systeem te onderhouden is en hoe schaalbaar het is. De tools zijn echter niet bedoeld om alle code en systemen streng te controleren, vertelt Heijstek.
“Als je de feiten kent over risico’s en code kwaliteit, kun je daar op gaan acteren. Hoe je dat doet is een tweede. Het gaat niet om de controle. Dat is niet een relatie die je met je ontwikkelaars op moet willen bouwen. Je moet ze juist helpen om technical debt te voorkomen. Daarbij is belangrijk dat het echt helder is wat je precies wil bereiken, en dat je tooling gebruikt ter ondersteuning van de ontwikkelaars.”
Technical debt wordt al snel als iets slechts gezien wat direct opgelost moet worden. Maar dat is niet altijd het geval. “Het gros van de technical debt moet je eigenlijk gewoon links laten liggen”, vindt Heijstek. “Dat is deels omdat technical debt nu eenmaal voorkomt in je legacy systemen. Maar de aanwezigheid van technical debt kan ook gewoon prima zijn als je niet of beperkt aan dat deel van de software hoeft te komen.”
Ook Vinju vindt dat technical debt niet altijd een groot probleem is. “Sommige mensen lenen geld om iets te doen wat ze anders niet hadden kunnen doen. Dat geldt ook voor technical debt”, legt hij uit. “De feedback cycle met een klant wordt bijvoorbeeld veel korter als je snel een eerste versie van een product levert en later terugkomt om de code te verbeteren. Maar dan ben je er wel achter of dit is wat de klant wil. Dat ligt veel dichter bij de agile losoe: maak eerst maar iets wat werkt, in plaats van dat je iets voor een toekomst maakt die nooit komt.”
Bovendien kun je ook aan overdesign doen: “Als je met alle toekomsten rekening gaat houden, kun je uiteindelijk helemaal niks meer. Je gaat dan overal vragen bij stellen. Wat als de programmeertaal uiteindelijk verandert? Wat als we gaan fuseren? Je kunt niet overal rekening mee houden. Je moet dus nadenken over de context en praten met stakeholders, en zo keuzes maken wat er wel en niet relevant is qua verwachtingen.”
Bij het aanpakken van technical debt is het dan ook belangrijk om altijd de afweging te maken welk deel je precies aanpakt. Volgens Heijstek spelen daarbij drie factoren een rol: “Je moet kijken welke code je veel aanraakt of veel aan gaat raken, welke van lage onderhoudbaarheid is en of er code is waarvan het risico laag is dat er iets stuk gaat als je het refactored.” Code of stukken software die aan deze factoren voldoen, zijn een kandidaat voor het afbetalen van schuld. Zo ontstaat dus een shortlist van projecten, de rest kun je laten liggen.
Bron: AGConnect – 03/03/2020 (Auteur: Eveline Meijer, Redacteur AG Connect)
We'll keep you posted on the latest news, events, and publications.
