Technische schuld: wat het is en waarom het ertoe doet
Je developer heeft het over technische schuld. Klinkt abstract, klinkt als zijn probleem. Maar het is ook jouw probleem. Een uitleg voor niet-developers.
Je developer zegt dat er technische schuld is. Klinkt abstract. Klinkt als iets waar jij je niet mee bezig hoeft te houden. Toch is het belangrijk om te begrijpen wat het betekent.
De metafoor van schuld
Technische schuld werkt als financiële schuld. Je leent van de toekomst om nu sneller te kunnen bewegen.
Stel, je hebt een deadline en te weinig tijd. Je developer bouwt iets dat werkt, maar niet netjes is. Shortcuts, quick fixes, code die doet wat het moet maar moeilijk te begrijpen is.
Je haalt de deadline. Maar je hebt geleend. De rente betaal je later, in de vorm van langzamer werken, meer bugs, hogere kosten voor aanpassingen.
Hoe technische schuld ontstaat
Soms bewust, soms onbewust.
Tijdsdruk. De meest voorkomende oorzaak. Er moet iets live, nu. Geen tijd om het goed te doen, dus wordt het werkend gedaan.
Veranderende eisen. Wat je bouwt is gebaseerd op wat je toen wist. Later blijkt dat het anders moet. De oude code past niet meer, maar wordt niet aangepast.
Gebrek aan kennis. Een junior developer weet niet wat hij niet weet. Hij bouwt iets dat werkt maar niet schaalbaar is. Pas later wordt duidelijk dat het een probleem is.
Geen onderhoud. Software veroudert. Frameworks krijgen nieuwe versies, best practices veranderen. Code die ooit prima was, is nu achterhaald.
Waarom het ertoe doet
Een beetje technische schuld is normaal. Elk project heeft het. Het probleem ontstaat als het zich opstapelt.
Ontwikkeling wordt trager. Elke nieuwe feature moet om de oude rommel heen gebouwd worden. Wat ooit een dag kostte, kost nu een week.
Bugs nemen toe. Complexe, slecht gestructureerde code is moeilijker te testen. Fouten sluipen erin en zijn lastig te vinden.
Developers haken af. Niemand werkt graag in een codebase die een puinhoop is. Je beste mensen vertrekken, nieuwe mensen zijn moeilijk te vinden.
Het systeem wordt fragiel. Op een gegeven moment durft niemand meer iets aan te passen. De angst om dingen te breken verlamt de ontwikkeling.
Hoe herken je het?
Je hoeft geen developer te zijn om de symptomen te zien.
Simpele wijzigingen kosten onverklaarbaar veel tijd. Een knop verplaatsen wordt een weekproject.
Dezelfde bugs komen steeds terug. Of nieuwe features introduceren onverwachte problemen elders.
Je developer zucht als je vraagt om iets aan te passen in een bepaald deel van de applicatie.
De onuitgesproken regel wordt: raak dat stuk niet aan.
Wat kun je eraan doen?
Erken dat het bestaat. De eerste stap is accepteren dat technische schuld geen falen is maar realiteit. Elk project heeft het.
Maak het bespreekbaar. Vraag je developer regelmatig naar de staat van de code. Niet om te controleren, maar om te begrijpen.
Reserveer tijd. Plan structureel tijd in om schuld af te lossen. Een vuistregel is twintig procent van de ontwikkeltijd besteden aan opruimen.
Voorkom dat het erger wordt. Nieuwe code hoort schoon te zijn. Sta niet toe dat tijdsdruk steeds opnieuw als excuus wordt gebruikt.
Accepteer dat het geld kost. Schuld aflossen voelt als investeren in iets dat al werkt. Maar het is investeren in de toekomst. Een gezonde codebase bespaart op de lange termijn.
Tot slot
Technische schuld is geen schande en geen ramp. Het is een realiteit waar je bewust mee om moet gaan. Negeren maakt het erger. Erkennen en aanpakken houdt je software gezond.
Vraag je developer hoe het ervoor staat. Het antwoord kan confronterend zijn, maar je bent beter af als je het weet.