"Technical debt", het is een beladen term die veel CTOs hoofdbrekens bezorgt.

Laat me beginnen met een wijdverspreid misverstand uit de weg te helpen: "technical debt" is niet noodzakelijk het gevolg van slechte beslissingen. Het is een gevolg van beslissingen die achteraf gezien en in de huidige omstandigheden niet optimaal waren. Dat kan omdat je meer geleerd hebt, of omdat je bedrijf van richting is veranderd, of omdat de schaal waarop je opereert is veranderd, of omdat de technologie waarmee je werkt aan een upgrade toe is.

Waarom zou je technical debt oplossen? Hoe meer technical debt je hebt, hoe moeilijker het wordt om nieuwe features te bouwen. Je sleept een hoop balast mee die je meer en meer vertraagt.

Er zijn een aantal strategieën om technical debt te reduceren:

• Negeer het. Het grote nadeel is dat je trager en trager vooruit zal gaan.

• Start from scratch. De meest voor de hand liggende oplossing, maar helaas meestal de slechtste. Wanneer je helemaal opnieuw begint denk je "we gaan dezelfde fouten niet meer maken!" Dat klopt (ten dele), maar je gaat zeker en vast andere fouten maken. Bovendien zit je met een periode dat je twee code bases moet onderhouden: degene die je klanten gebruiken, en de nieuwe "ideale" code base. Dat is een gegarandeerde bron voor veel hoofdpijn.

• Werk iteratief. Schaaf hier wat weg, schaaf daar wat weg. Belangrijk is om te zorgen dat je niet te grote maar ook niet te kleine onderdelen van je code base aanpakt. Te groot, en je effort is niet meer te behappen. Te klein, en je ziet geen enkele vooruitgang.

• Zorg dat de stappen die je zet zichtbaar zijn, en waarde op zich hebben. Alleen zo krijg je een gevoel van vooruitgang, en kan je die vooruitgang aantonen aan de mensen buiten je software-ontwikkelings-team.

• Zet het wegwerken van technical debt op je roadmap. Dit maakt het voor het hele bedrijf inzichtelijk dat je daarmee bezig bent, maar de ontwikkeling van nieuwe features staat wel even stil.

• Zet een deel van je mensen op het wegwerken van technical debt, en een ander deel op het ontwikkelen van nieuwe features. Zo blijf je voortgang maken in je features, zij het met beperkte capaciteit. Je krijgt extra zorgen om de twee teams gealigneerd te houden. Bovendien is het vaak niet voor iedereen duidelijk waarom de ontwikkelingssnelheid plotseling trager is.

De "silver bullet" heb ik nog niet ontdekt, maar het zal je zeker helpen om bewust een beslissing te maken tussen deze strategieën.