Technische schuld

Hoe ontstaat technische schuld?

Meestal met de beste bedoelingen. Er moet iets af voor een demo, dus wordt een berekening op drie plekken gekopieerd in plaats van één keer goed opgezet. Een uitzondering voor één klant wordt er even ingeplakt. Een koppeling wordt gebouwd zonder foutafhandeling, omdat het andere systeem toch nooit plat ligt.

Elke keuze afzonderlijk is te verdedigen. Opgeteld krijg je software waarin niemand meer precies weet wat er gebeurt als je ergens aan draait.

Tegenwoordig ontstaat het ook sneller dan ooit. Met vibe coding staat er in een middag een applicatie, en wie daarop blijft doorbouwen zonder naar de code te kijken, stapelt in weken een schuld op waar vroeger jaren voor nodig waren.

Hoe herken je technische schuld?

Aan de gesprekken. "Dat kan, maar dan moeten we eerst …" wordt een vaste zin. Kleine wijzigingen kosten ineens dagen. Na elke update gaat er iets anders stuk, op een plek die er niets mee te maken leek te hebben. En er is één persoon die weet hoe het zit, en iedereen is bang dat die vertrekt.

Als ondernemer zie je de code niet, maar dit soort signalen wel. Ze zijn bijna altijd een teken dat de rente hoger is geworden dan de aflossing zou kosten.

Is technische schuld altijd slecht?

Nee. Een prototype of een MVP mag schuld bevatten, want het doel is snel leren of het idee werkt. Daar perfecte code voor schrijven is zonde van de tijd.

Het gaat mis als niemand bijhoudt dat het schuld is. Als het prototype stilletjes het productiesysteem wordt, zonder dat iemand heeft besloten wat er eerst opgeruimd moet worden. Daarom zeg ik bij een snel gebouwde eerste versie altijd hardop welke keuzes tijdelijk zijn, zodat we er later bewust op terug kunnen komen.

Hoe los je technische schuld af?

In kleine stappen, naast het gewone werk. Elke keer dat je een onderdeel aanpast, laat je het iets beter achter dan je het aantrof. Grote verbouwingen waarbij alles tegelijk wordt herschreven, lopen bijna altijd uit en leveren onderweg niets op.

Wat daarbij helpt: automatische tests en CI/CD, zodat je durft op te ruimen zonder bang te zijn dat je iets anders sloopt. Hoe ik dat in een traject meeneem, staat op Applicatieontwikkeling.