Laat technische schuld niet langer je roadmap bepalen—neem nu de controle met 5 strategieën

“Technische schuld is onvermijdelijk wanneer je opschaalt,” zegt Watkins, “maar bedrijven zijn vaak terughoudend om middelen toe te wijzen aan zaken die niet zichtbaar kapot zijn, vooral wanneer er nieuwe functionaliteit moet worden gelanceerd.” Op de lange termijn kan deze mentaliteit van "als het niet kapot is, hoef je het niet te repareren" echter tot 20% van de ontwikkelbudgetten opslokken.

Nu de vraag naar snellere releases en schaalbare systemen groter is dan ooit, leiden uitgestelde oplossingen vandaag tot grotere problemen morgen. Zo pak je technische schuld strategisch aan zonder je productplanning tot stilstand te brengen.

Wat is technische schuld?

Technische schuld is de opgebouwde herwerkkost wanneer snelheid in het ontwikkelproces belangrijker is dan kwaliteit op de lange termijn. Dit komt in verschillende vormen tot uiting:

• Architecturale schuld: Wanneer je systeemarchitectuur de behoeften van groei of schaalvergroting niet kan bijhouden.
• Code-schuld: Code van lage kwaliteit of slecht geteste code die instabiliteit in productie veroorzaakt en tot veelvuldige storingen leidt.
• Procesmatige schuld: Inefficiënties in workflows, een gebrek aan geautomatiseerde processen of een defecte CI/CD-pipeline die knelpunten veroorzaakt.
• Documentatieschuld: Ontbrekende of verouderde documentatie, afhankelijkheid van teamleden met niet-vastgelegde kennis en meer moeite bij het oplossen van problemen en het inwerken van nieuwe medewerkers.
• Infrastructuurschuld: Werken met verouderde versies van afhankelijkheden of het verwaarlozen van rampherstel, wat kan leiden tot kwetsbaarheden en systeemstoringen.

Oorzaken van technische schuld

Je kunt niet repareren wat je niet begrijpt. Weten waarom je technische schuld toeneemt, is essentieel om te voorkomen dat deze uit de hand loopt. Dit zijn belangrijke oorzaken van technische schuld om in de gaten te houden:

• Toenemende bedrijfsdruk: De haast om snel te leveren leidt vaak tot een ongecontroleerde uitbreiding van de projectomvang, overbelaste ontwikkelmiddelen, overgeslagen tests en slecht ontworpen functies die later, als dat al gebeurt, moeten worden gerepareerd. 
• Verouderde systeemarchitectuur: Vasthouden aan verouderde systemen en niet migreren wanneer dat nodig is, creëert kwetsbare integraties en meer technische schuld. Verouderde API's en authenticatiesystemen worden vaak opgestapeld met meerdere aanbieders.
• Slecht ontwikkelproces: Al te soepele of niet-bestaande codereviews, gedupliceerde code met een lage leesbaarheid en grote codebases met meer dan 1 miljoen regels code (LoC). 
• Complexiteit van verouderde systemen: Uitgestelde patches, verouderde infrastructuur en niet-ondersteunde versies leiden tot incompatibiliteit tussen systemen en een zich opstapelende “beveiligingsschuld”. Microsoft probeert hier nog steeds van te herstellen. Tussen de inbraak in Exchange Online en de aanval van Midnight Blizzard betalen ze nog steeds de prijs voor het negeren van de schuld die zich in de loop der tijd heeft opgebouwd.
• In silo's opgeslagen kennismanagement: Slechte technologische keuzes, een ontoereikende implementatie van ontwerppatronen en verkeerd gebruik van raamwerken kunnen teams tot onnodig complexe oplossingen dwingen, zoals het invoeren van microservices zonder expertise in gedistribueerde systemen.
• Lage productiviteit van ontwikkelaars: Ontwikkelaars die voortdurend onder druk staan en geen tijd hebben om documentatie te beoordelen of diepgaand werk te doen, zullen altijd kortetermijndoelen prioriteren, waardoor de technische schuld kan toenemen. 

De meest effectieve strategieën voor het beheren van technische schuld pakken deze grondoorzaken aan in plaats van alleen de symptomen te bestrijden.

5 stappen voor CTO's om technische schuld te verminderen

Technische schuld is vaak een bewuste beslissing, vooral wanneer het doel is om snel een MVP te lanceren, met plannen om later te herstructureren als het succesvol is. Het werkt– totdat het niet meer werkt. Dus als je dat kantelpunt hebt bereikt of proactief wilt blijven, zijn hier vijf strategieën rechtstreeks uit het draaiboek van de CTO om die groeiende technische schuld aan te pakken: 

1. Maak je technische schuld zichtbaar 

Je kunt niet oplossen wat je niet kunt meten, maar zoals Martin Riley, CTO bij Bridewell, zegt, kun je ook niet meten wat je niet kunt zien. Dat betekent dat je ervoor moet zorgen dat je ontwikkelwerk helemaal kan worden teruggevoerd naar de technische schuld die het veroorzaakt. Met die zichtbaarheid kun je technische investeringen afstemmen op bedrijfsdoelen, inspanningen voor herstructurering onderbouwen en onverwachte systeemstoringen voorkomen. “Als je weet wie verantwoordelijk is voor de code die schuld veroorzaakt en of die is goedgekeurd, wordt het eenvoudiger om dit te beheren.”

Gedetailleerd inzicht in je technische schuld begint met betrouwbare gegevens. Gebruik een AI-agent die verbinding maakt met je CI/CD-pijplijn, gegevens uit teamvergaderingen ophaalt en communicatiepatronen, werkverdeling en sprintvoortgang bijhoudt. Je kunt zelfs het registreren automatiseren om verouderde of complexe code te signaleren en tegelijkertijd te monitoren hoe je codekwaliteit in de loop der tijd verbetert of achteruitgaat. Combineer deze inzichten met regelmatige enquêtes waarin IC's de moeilijkheid van codewijzigingen, de aan onderhoud bestede tijd en knelpunten kunnen beoordelen. 

2. Voer een schuldenregister in om prioriteiten toe te kennen 

Maak een centraal register van technische schuld waarin alle vormen van schuld worden vastgelegd: code, architectuur en procesdocumentatie. Maar het opsommen van bronnen van technische schuld is niet genoeg; de lastigere taak is vaststellen welke gebieden de grootste impact zullen hebben. Watkins adviseert om te focussen op ROI: “Als een oplossing twintig ontwikkelaars elke dag een uur bespaart en slechts een week kost om te implementeren, levert dat vrijwel direct rendement op.” Hij ziet vergelijkbare opbrengsten bij het aanpakken van problemen zoals instabiele tests of lange bouwtijden. 

Volg bij het opstellen van je schuldenregister de 80/20-regel: richt je op de 20% van de technische schuld die 80% van je problemen veroorzaakt. Breng de kritieke “20%” in kaart door het volgende bij te houden: 

• Onderhoudstijd versus ontwikkeling van nieuwe functies
• Aantal terugkerende en onopgeloste bugs
• Feedback van ontwikkelaars over de moeilijkheid van wijzigingen
• Percentage testdekking
• Bouwtijden (10 minuten of langer)
• Hoge percentages herschreven code (meer dan 20% per sprint)

Kwantitatieve meetgegevens geven je de harde feiten, maar je hebt ook de kwalitatieve kant nodig om een volledig beeld te krijgen van hoe en waar je technische schuld zich opbouwt en welke onderdelen van het bedrijf daar het meeste last van hebben.

Watkins adviseert om gebruikerservaringsproblemen, langere implementatietijden en het grootste probleem van allemaal in de gaten te houden– afnemende productiviteit binnen je ontwikkelteam. Denk aan de uren waarin je ontwikkelaars diepgaand werken, CSAT-scores van klanten die klagen over uitvaltijd, trage laadtijden en onbetrouwbare builds in productie. Maak dit onderdeel van je reguliere workflow door je register te integreren met JIRA en voor elke categorie een ‘Eigenaar van de schuld’ aan te wijzen, zodat je de situatie goed kunt blijven volgen. 

3. Integreer technische schuld in je sprintplanning 

Jeff Delaney, VP Engineering voor R&D bij Black Duck, heeft een slimme aanpak voor het beheren van technische schuld: neem deze op in je capaciteitsplanning met kwartaaldoelen en een JIRA-bord. “We zorgen ervoor dat we in elke release een vaste hoeveelheid capaciteit reserveren voor technische schuld. De hoeveelheid kan variëren, maar we weten altijd welke technische schuld we hebben, stellen er prioriteiten aan en geven deze de juiste aandacht.”

Begin met rotaties van 45 dagen waarin ontwikkelaars afwisselend verouderde systemen onderhouden en nieuwe functies bouwen. Laat ze tijdens de wissel samenwerken om nieuwe perspectieven en een goede kennisoverdracht mogelijk te maken. Samenwerken in duo's verdeelt de onderhoudslast op natuurlijke wijze, geeft iedereen een dieper inzicht in het systeem en creëert begrip voor de minder glamoureuze taken op het gebied van "onderhoud". 

De uitdaging is echter om draagvlak te krijgen van de directie, vooral als zij ontwikkelaars aan verouderde systemen zien werken in plaats van nieuwe bedrijfsdoelen na te streven. Watkins stelt voor om tijd voor herstelwerkzaamheden op te nemen in je ontwikkeltickets en een mentaliteit te hanteren van “los het op voordat je het uitbreidt”. “De oplevering kan aanvankelijk vertragen, maar het resultaat op lange termijn zal zowel aan technische als aan zakelijke doelstellingen voldoen.”

4. Bouw ‘schuldpoorten’ in de CI/CD-pijplijn

Technische schuld voorkomen is goedkoper dan deze later opruimen– beperk haar terwijl ze nog onschadelijk is. Zet een programma voor architectuurbeslissingsrecords (ADR) op met een standaardsjabloon om alternatieven, beslissingscriteria en de verwachte impact van technische schuld vast te leggen. Sla dit samen met je code op in versiebeheer. ADR's helpen onbedoelde technische schuld te voorkomen en toekomstige herstructureringsinspanningen te sturen. Maar ADR's geven je slechts een overzicht vanuit vogelperspectief. 

Een echte, dagelijkse vermindering van technische schuld komt echter voort uit het opleveren van code van hoge kwaliteit. Je kunt je AI-agent of hulpmiddel voor codeanalyse gebruiken (als je nog niet klaar bent voor AI) om automatisch problemen te markeren wanneer bepaalde benchmarks worden overschreden:

• Blokkeer implementaties wanneer de cyclomatische complexiteit 15 bereikt
• Markeer tests als instabiel na 3 willekeurige fouten
• Laat builds mislukken als testsuites langer dan 10 minuten duren
• Stop pull requests wanneer klassen met 500+ regels klaarstaan om te worden samengevoegd 

Gebruik voor afhankelijkheden aangepaste scripts om implementaties met risicovolle afhankelijkheden te blokkeren en samenvoegingen met conflicterende versies te voorkomen. Koppel je script bijvoorbeeld aan een CSV-beveiligingsdatabase om automatisch implementaties te blokkeren die kwetsbare pakketten bevatten. Je kunt ook scripts schrijven om te voorkomen dat pull requests worden samengevoegd als ze conflicterende afhankelijkheden creëren of verouderde bibliotheken gebruiken. 

De keuzes van The CTO Club voor de beste DevOps-tools!

1. 

   TestDevLab

   Visit Website
2. 

   Site24x7

   This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   4.7

   Visit Website
3. 

   GitHub Actions

   This rating combines scores from multiple user review sites to reflect overall customer sentiment about the product.

   4.8

   Visit Website

5. Moderniseer je verouderde infrastructuur 

Veel bedrijven hebben moeite met moderniseren omdat ze vastzitten aan monolithische architecturen die agileontwikkeling en releases vertragen. Riley stelt voor het Strangler-patroon te gebruiken om technische schuld geleidelijk aan te pakken, in plaats van alles in één keer te proberen herschrijven.

In plaats van een risicovolle migratie waarbij alles in één keer wordt overgezet, moderniseer je je verouderde technologie stapsgewijs, functie voor functie of gebruikersgroep voor gebruikersgroep, om verstoring te beperken en onderweg feedback te verzamelen.

Sommige grote teams gebruiken een parallelle aanpak, zoals Spotify deed voor hun muziekspeler. Ze hielden de web- en desktopversies met dezelfde interface actief om gegevens te synchroniseren en het nieuwe systeem te testen voordat ze volledig migreerden.

Doorbreek technische schuld voordat die je vooruitgang belemmert

Technische schuld is niet altijd iets slechts – het is eigenlijk een teken dat je engineeringteam groeit. De betere vraag is: beheer jij de technische schuld, of beheert die jou? Zoals Delaney het zegt: “Uiteindelijk moet het team zich toch met technische schuld bezighouden. De sleutel is om dit op jouw voorwaarden te doen door zorgvuldig te plannen, in plaats van later in crisismodus te moeten improviseren.” 

Leiders moeten ophouden te wachten tot problemen escaleren en nu beginnen te investeren in efficiëntie, uitvoering en kostenoptimalisatie.

Wil je op de hoogte blijven van alles rondom technische schuld en leiderschap? Abonneer je vandaag nog op de nieuwsbrief van The CTO Club.