“Technical Debt” is een van die moderne buzzwords.

Je legt een requirement op tafel. Nog voordat je goed en wel hebt uitgelegd waarom het belangrijk is, klinkt het al: “Nee, dat is technical debt!”

Einde discussie. Want alles moet tegenwoordig out of the box.

Is dat dan zonder consequenties?

Accepteren we bijvoorbeeld dat iemand aan de andere kant van de wereld jouw data kan wijzigen, omdat het beperken van die rechten als technical debt wordt gezien?

Ik dacht altijd dat we IT-processen automatiseerden om ze sneller, slimmer en vooral betrouwbaarder uit te voeren. Met minder handwerk, de juiste kennis in de tooling en als resultaat een administratie waarop je kunt vertrouwen.

Dat lijkt veranderd.

Ik neem aan dat iemand de consequenties van die keuze zorgvuldig heeft afgewogen.

Of niet?

Want welke schuld bouwen we ondertussen ergens anders op? Process debt? Quality debt? Verborgen-kosten-debt?

En hoe maken we die afweging eigenlijk, als het woord technical debt het gesprek al heeft beëindigd voordat het begonnen is?

Misschien wordt het tijd om niet alleen te definiëren wat technical debt is, maar ook wat het kost om het koste wat kost te vermijden.

Ook dit soort vraagstukken komen aan bod in mijn CMDB MasterClass.