Definitie
Technische schuld (Engels: technical debt) is een metafoor voor het toekomstig werk dat ontstaat omdat eerder snelle, suboptimale of uitgestelde technische keuzes zijn gemaakt. Net als financiële schuld kun je er soms bewust voor kiezen (om snel iets te lanceren), maar als je niet aflost, groeit het met rente.
Schuld is niet altijd slecht. Soms is het de juiste keuze om snel iets minder netjes te bouwen om een markt of klantkans te grijpen. Het wordt pas een probleem als er geen plan is om de schuld af te lossen, en het systeem geleidelijk onaanpasbaar wordt.
Waarom het ertoe doet voor MKB
Voor MKB met eigen software is technische schuld een onzichtbare maar reële kostenpost. Een systeem dat 5 jaar geleden in een weekend gebouwd werd, kan inmiddels één miljoen euro aan accumulatieve schuld bevatten: trage features, onbetrouwbare uitrol, ontwikkelaars die niemand meer durft te laten gaan.
Voor jouw bedrijf is het belangrijk om bewust te zijn van schuld. Vraag bij elk softwareproject: welke schuld leveren we hierbij in, en wanneer en hoe lossen we die af? Zonder dat gesprek is schuld onzichtbaar, en daarmee gevaarlijk.
Concreet voorbeeld
Een groothandel liet 7 jaar geleden een webshop bouwen door een freelancer die “snel iets neerzette” zonder testopzet, zonder documentatie, en met veel handmatige stappen. De webshop draaide en bracht omzet op.
Vijf jaar later was de freelancer vertrokken, en bleek dat elke kleine aanpassing dagen kostte. De code was niemand begrijpelijk, een fout kon de hele webshop platleggen, en niemand durfde nog grote wijzigingen aan. De schuld was zo groot geworden dat een herbouw goedkoper bleek dan doorbouwen op het bestaande. Wat 7 jaar eerder een “slimme korting” leek, betaalde zich uiteindelijk duur uit.
Misverstanden en valkuilen
- “Technische schuld is alleen iets voor techies.” De bedrijfsimpact is reëel: tragere innovatie, hogere kosten, meer downtime. Directie zou bewust moeten zijn van het schuldniveau.
- “Schuld is altijd slecht.” Niet noodzakelijk. Bewust schuld nemen om snel een MVP te lanceren is legitiem. Wel: maak een plan voor aflossing.
- “Een herbouw lost het op.” Soms ja, vaker creëert een herbouw nieuwe schuld. Refactoring in stapjes is meestal duurzamer.
- “De schuld is meetbaar.” Lastig in euro’s, maar wel signaleerbaar: snelheid van wijzigingen, aantal bugs, tevredenheid van ontwikkelteam. Daar zit informatie in.
Wanneer moet je hier wakker liggen, wanneer niet
Wakker liggen: als nieuwe features steeds langer duren, ontwikkelaars vertrekken omdat het systeem onhoudbaar is, of als jullie nooit tijd hebben om iets fundamenteel te verbeteren. Dat zijn signalen van gevaarlijke schuld.
Niet wakker liggen: als je vooral SaaS-tools gebruikt. De schuld zit dan bij de leveranciers, en jij ondervindt het hooguit indirect. Wel: vraag bij leveranciers naar hun ontwikkelroadmap als signaal van schuld-niveau.
Gerelateerde termen
- Refactoring: de manier om technische schuld af te lossen.
- MVP: een MVP brengt vaak gepland schuld met zich mee.
- Monolith: oude monolieten dragen vaak veel schuld.
- Build vs buy: zelf bouwen brengt schuld; kopen schuift schuld naar leverancier.