Koen Van den Wijngaert was de eerste om in te gaan op mijn AMA uitnodiging (AMA: Ask Me Anything: stel me eender welke vraag rond Software Engineering Leadership en ik geef je een antwoord)

Zijn vraag: “How to deal with legacy code and technical debt without freezing all features for a year?”

Die vraag valt uit elkaar in een aantal delen, waarbij het ene deel gelukkig mee zorgt voor het antwoord op een ander deel.

De eerste vraag die je je kan stellen is “welke legacy code en welke technical debt hebben we?” Soms denk je dat je daar een zicht op hebt, maar zijn er delen van de code die je ook meesleept maar waar je geen idee van hebt – vooral als je zelf al wat verder van de code staat.

Een volgende vraag is “welke van die technical debt moeten we oplossen?” Ja, technical debt heeft een kostprijs, maar het wegwerken van technical debt heeft óók een kostprijs. Wat weegt door?

“Welke van die technical debt moeten we nú oplossen?” Er zijn ongetwijfeld zaken die nu al pijn doen, en er zijn zaken waarvan je weet dat ze over een tijdje pijn gaan doen.

“Van al hetgeen overblijft – wat gaan we eerst doen?” Als je die vraag hebt beantwoord, heb je tenminste al een roadmap om die technical debt aan te pakken.

En nu komt het punt waarop je de Software Engineers van de Leaders kan onderscheiden. Een Engineer zal zeggen “stop alles - we moeten nú die technical debt aanpakken, en alles moet daarvoor wijken!” In het meest extreme geval resulteert dit in “we gooien alle bestaande code weg en we beginnen opnieuw. Deze keer doen we het wél goed!”

Spoiler alert: deze keer doe je het niét beter. Je maakt misschien niet dezelfde fouten – maar ik geef je op een briefje dat je andere fouten zal maken. Die ook weer voor technical debt zorgen achteraf.

Een alternatieve oplossing is The Great Refactor. We gooien niet àlles weg, maar we refactoren alles tot het is zoals het moet zijn. Terwijl we daaraan bezig zijn kan de code niet in productie gezet worden, want we breken een hoop zaken. Ook dit is zelden een goed idee: hoe langer die refactor duurt, hoe groter de kans dat er toch iets tussen komt dat Dringend Is En Nu Moet Opgelost Worden. Vanaf dat moment zit je met twee gescheiden code bases, met alle hoofdbrekens vandien.

Hoe kan je dan wel technical debt aanpakken? Wel, net zoals je een olifant eet: in kleine stukjes.

De Leaders die ik succesvol technical debt heb zien oplossen, werken in kleine stapjes. Je voorziet een vast “budget tijd” om aan technical debt te werken – dat kan zijn “elke week een dag”, of “elke week één engineer die eraan kan werken”, tot zelfs “na elke sprint van 3 weken nemen we een week cooldown, waarin we de volgende sprint voorbereiden maar ook aan de technical debt werken” Je houdt je hierbij aan de principes van modern software engineering: zorg dat je altijd iets deploybaar hebt. Dat kan een uitdaging lijken, en je kan het gevoel hebben dat je niet vooruit gaat. En in het begin is dat ook zo. Maar naarmate je je code incrementeel elke keer een beetje beter maakt, gaan je volgende inspanningen sneller vooruit gaan en meer opbrengen. En dat alles terwijl je de product managers en de sales mensen tevreden houdt!

Dus, Koen: zoek een stukje dat veel pijn doet, dat veel oplevert, en dat idealiter heel zichtbaar is. Werk daaraan en laat zien dat het vooruitgaat en dat het opbrengt. Zelfs je product managers gaan na een tijdje tevreden zijn als ze beginnen merken dat hun features sneller vooruit gaan.

Timmer dan geduldig verder aan de ingeslagen weg.