Technische schuld aanpakken zonder alles stil te leggen

Technische schuld wordt een lastig gesprek wanneer de ene kant rommelige code hoort en de andere kant opnieuw een reden waarom de gevraagde functie later komt. Beide missen de nuttige vraag: wat kost dit deel van het systeem wanneer we het aanpassen of gebruiken?

Beschrijf het gevolg, niet de leeftijd

Oude software is niet automatisch slechte software. Een stabiele module die zelden verandert, vraagt misschien weinig aandacht. Een recenter onderdeel dat releases geregeld stukmaakt, kan veel nuttiger zijn om aan te pakken. Leeftijd en mode vervangen geen onderbouwing.

Maak het gevolg concreet. Misschien vraagt elke prijswijziging aanpassingen in drie diensten, heeft een release een manuele databasestap nodig of merkt pas een klant een mislukte koppeling op. Zulke vaststellingen verbinden het technische probleem met vertraging, operationeel risico of vermijdbaar werk.

Kies één bruikbare afbakening

Een brede vraag om de architectuur op te kuisen is moeilijk goed te keuren en nog moeilijker af te maken. Een afgebakende ingreep kan je wel bespreken: automatiseer de kwetsbare releasestap, test een kritische berekening, isoleer een instabiele leverancierskoppeling of verwijder een dubbele regel uit het volgende ontwikkeltraject.

• Welk terugkerend probleem pakt deze wijziging aan?
• Wat blijft werken terwijl we de aanpassing maken?
• Hoe merken we een regressie en kunnen we herstellen?
• Wie maakt de verbetering af en controleert het resultaat?

Verbind verbetering met de volgende echte wijziging

Past het team de bestelstroom toch al aan, dan kan dat het goede moment zijn om de bedrijfsregels met tests te beschermen. Een rapportmodule die niemand aanraakt herstructureren omdat de stijl oud aanvoelt, overtuigt minder. Werk aan een echte wijziging verbinden geeft context en een natuurlijke controle op het resultaat.

Dat betekent niet dat je structureel werk in elke raming moet verstoppen. Maak de keuze zichtbaar. Soms verdient een verbetering een eigen korte opdracht omdat de operationele gevolgen groot genoeg zijn. De directie moet begrijpen wat ze ermee koopt en welk ander werk daarvoor wijkt.

Houd het leren klein genoeg om te gebruiken

Leg vooraf een eenvoudige beginsituatie vast: de manuele stappen, een terugkerende fout of de moeite om de betrokken regel te veranderen. Controleer achteraf hetzelfde. Je hebt geen universele technische-schuldscore nodig om te weten of een riskante releasestap verdwenen is.

Een herbouw vraagt nog altijd een bedrijfsreden

Sommige systemen zijn echt aan vervanging toe. De redenering moet ook migratie, parallel draaien, gegevenscontrole, opleiding en ondersteuning bevatten, niet alleen nieuwe code. Een stapsgewijze overgang leert vaak meer dan een lange periode waarin de vervanger de bestaande taak nog niet aankan.

Ons artikel over verouderde systemen vervangen gaat op die overgang in. Fractional CTO-ondersteuning helpt verbeterkeuzes verbinden met bedrijfsprioriteiten en de echte capaciteit van het team.