Wat is technical debt?
Technical debt ontstaat wanneer eerder geschreven code het moeilijk maakt om huidige aanpassingen door te voeren. Code die nu lastig is om te begrijpen, uit te breiden of te onderhouden.
Net zoals bij echte schulden moet je die technische schuld op een bepaald moment “terugbetalen” met extra werk, bugs of vertragingen bijvoorbeeld.
Technical debt is vergelijkbaar met Tetris: zodra er gaten ontstaan, kost het extra moeite om ze op te vullen, en blijven ze anders een obstakel. Kijk je weg en laat je het zo, dan draag je daar vroeg of laat de gevolgen van. Niet altijd natuurlijk, je kan op de 3de rij van Tetris ook gewoon verder blijven spelen maar het verkleint je ruimte mocht er later iets fout loopt.
Hoe en waarom ontstaat het?
Bij het ontwikkelen van software maak je keuzes gebaseerd op de kennis en omstandigheden van dat moment. Soms zijn deze keuzes ingegeven door tijdsdruk of beperkte informatie, wat kan leiden tot technical debt. Je zit dus met de kennis van de developer, die ook maar kan weten wat die weet.
Een tweede mogelijke oorzaak is dat die keuze gemaakt is op een slecht moment. De developer kan onder tijdsdruk staan om een deadline te halen, of de beslissing genomen hebben op een moment van verminderde concentratie.
Maar ook als er vroeger de juiste keuze is gemaakt, kan het dat de scope veranderd en er een aanpassingen gemaakt moet worden. Dan kan er, vaak om tijd te winnen, gekozen worden om enkele zaken van de oude manier van werken, te laten staan.
Wat zijn de gevolgen?
Net zoals financiële schuld, is technische schuld niet per se slecht. Soms was het een investering. Maar als je het blijft negeren en het niet wegwerkt, wordt het problematisch.
Je merkt het vaak aan:
- Trage ontwikkeling: simpele aanpassingen duren plots dagen
- Meer bugs en fouten
- Minder motivatie bij developers (frustratie)
- Moeilijkere samenwerking in het team
- Hogere kosten op lange termijn
Hoe gaan wij om met technical debt?
Het is belangrijk om technical debt te erkennen. In veel projecten komen we legacy code tegen, zoals ongebruikte databasevelden of verouderde functies. De kunst bestaat erin om een balans te vinden tussen tijd maken om deze weg te werken en productiviteit. De Boy Scout Rule is hier een goede aanpak voor. Laat je code beter achter dan dat je het gevonden hebt. Zo kan je debt wegwerken de volgende keer je aan dat stuk van de applicatie werkt.
Voorkomen is beter dan genezen. In kleine iteraties werken, zorgt ervoor dat je vlug feedback krijgt en dat de verandering in de scope (en die komen er), er snel is waardoor de schade niet te groot is als je moet veranderen van functionaliteit.
We maken gebruik van automatische testen en code reviews om te voorkomen dat beslissingen op "slechte" dagen onopgemerkt blijven.
En soms is het gewoon nodig om eens door legacy code te ploeteren en technical debt weg te werken. Koppen naar beneden en werken.
