Technische schuld prioriteren: welke verbetering helpt het bedrijf werkelijk?

Vertaal een technisch label naar een concreet gevolg

Slechte architectuur is geen voldoende afgebakende bevinding. Leg uit welke wijziging daardoor moeilijk wordt, welke fout lastig terug te vinden is of welke beheertaak van één persoon afhangt. Een grote module kan jarenlang stabiel blijven, terwijl een klein script iedere maand handmatig moet worden gerepareerd. De omvang van de code zegt dus niet vanzelf welke verbetering als eerste waarde heeft.

Vraag om één recent voorbeeld. Welke handelingen waren nodig, waar ontstond onzekerheid en welk bewijs is beschikbaar? Noteer ook wanneer het probleem juist niet optreedt. Zo blijft de beschrijving toetsbaar. Een discussie over persoonlijke programmeervoorkeur kan dan plaatsmaken voor een gesprek over wijzigingstijd, foutkans of herstelbaarheid.

Maak verschil tussen soorten achterstand

Een ondersteunde maar lastig te begrijpen module vraagt misschien documentatie en gerichte tests. Een afhankelijkheid waarvoor geen bruikbare onderhoudsroute bestaat vraagt onderzoek naar vervanging of isolatie. Een onbekende back-upstatus vraagt eerst een hersteloefening. Hetzelfde label technische schuld verbergt anders dat de noodzakelijke eerste handeling telkens anders is.

Maak een indeling op de beslissing die nodig is: werking aantonen, verantwoordelijkheid regelen, een fout herstellen of een verandering eenvoudiger maken. Gebruik die indeling naast de technische categorie. Daarmee kan een opdrachtgever begrijpen waarom een accountoverdracht soms eerder komt dan een zichtbare productverbetering. De vraag is welke afhankelijkheid de organisatie nu belemmert, niet welke activiteit het aantrekkelijkst klinkt.

Maak een klein schuldenregister met bewijs

Een bruikbaar register bevat onderwerp, betrokken bedrijfsroute, waarneming, mogelijk gevolg en onzekerheid. Voeg een voorgestelde eerste stap toe. Een volledige herbouw is meestal te groot als eerste regel in zo’n register. Een onderzoek naar één koppeling of een test rond een foutgevoelige berekening is concreter en beter te beoordelen.

Beperk de eerste inventaris tot een beheersbaar aantal onderwerpen. Tientallen ongeordende opmerkingen geven een vals gevoel van volledigheid. Laat zien welke punten samenhangen en waar één ingreep meerdere klachten kan verminderen. Benoem daarnaast welke informatie ontbreekt. Een nog onbekend gevolg kan een reden zijn voor onderzoek, maar hoort niet als reeds aangetoonde schade te worden opgeteld.

Vergelijk gerichte verbeteringen met gefaseerde vervanging voordat je een volledige herbouw kiest: Bestaande software moderniseren of opnieuw bouwen: vergelijk de hele overgang.

Beoordeel gevolgen en timing afzonderlijk

Een probleem kan ernstig zijn maar alleen een functie raken die wordt uitgefaseerd. Een minder opvallende afhankelijkheid kan juist iedere geplande wijziging blokkeren. Bespreek daarom zowel de mogelijke gevolgen als het moment waarop handelen nodig is. Betrek de mensen die verantwoordelijk zijn voor het proces en voor de technische uitvoering.

Een eenvoudige volgorde kan bestaan uit eerst beheersbaar maken, daarna gericht veranderen en vervolgens opnieuw beoordelen. Die volgorde is geen universele scoreformule. Een ontbrekende herstelroute kan bijvoorbeeld eerst een tijdelijke uitwijkafspraak en een oefening vragen. Pas als bekend is wat ontbreekt, kan een passend technisch vervolg worden gekozen. Vermijd schijnprecisie door kans en schade zonder onderbouwing op nette cijfers te zetten.

Vergelijk twee verbeteringen met dezelfde aannames

Fictief voorbeeld: een team besteedt bij iedere release tijd aan een handmatige controle van ordertotalen. Er is ook een wens om de hele interface opnieuw op te bouwen. De eerste verbetering kan bestaan uit een vaste set controleorders en een herhaalbare vergelijking. Het team vergelijkt daarmee minder handmatig werk en beter verklaarbare fouten, niet alleen een nieuwe technische uitstraling.

Stel dat het team voor de planning zes vergelijkbare releases bekijkt. Noteer de eigen gemeten controletijd per release en de tijd om de controle te onderhouden. Vermenigvuldig alleen vergelijkbare werkzaamheden. Vrijgekomen capaciteit is niet automatisch een lagere personeelsrekening. Een grotere interfacevernieuwing kan nuttig zijn, maar moet worden beoordeeld op eigen gebruikers- en onderhoudsdoelen in plaats van dezelfde besparing te claimen.

Bescherm bestaand gedrag vóór je herstructureert

Een verbetering aan interne code moet de relevante bedrijfsregels behouden. Leg daarom eerst voorbeelden vast van het huidige bedoelde gedrag, inclusief uitzonderingen. Bestaand gedrag is niet automatisch gewenst gedrag: laat de proceseigenaar aangeven welke afwijkingen fouten zijn en welke historisch noodzakelijke afspraken vertegenwoordigen.

Kies controles die zichtbaar maken of de verandering de bedoelde uitkomst behoudt. Dat kan een berekening, export of complete gebruikershandeling zijn. Tests zijn hulpmiddelen met een afbakening; een geslaagde testset zegt niet dat iedere denkbare situatie is afgedekt. Noteer ook welke controle nog handmatig gebeurt. Dat is eerlijker en bruikbaarder dan een algemene belofte dat herstructurering geen risico kan hebben.

Google SRE: Testing for Reliability ↗

Verklein koppeling waar dat een doel dient

Als één onderdeel voortdurend wordt aangepast aan de betekenis van een extern systeem, kan een expliciete vertaalgrens helpen. Leg dan vast welke informatie binnenkomt, wat intern een geldige toestand is en welke uitzonderingen worden teruggegeven. Een extra laag is alleen zinvol wanneer de verantwoordelijkheid duidelijker wordt en de onderhoudslast niet slechts verschuift.

Microsoft beschrijft een anti-corruption layer als patroon om verschillende modellen te scheiden. Dat betekent niet dat iedere koppeling zo’n laag nodig heeft. Onderzoek eerst welke verandering je eenvoudiger wilt maken. Vraag bij een voorstel om een klein voorbeeld vóór en ná de grens, inclusief foutafhandeling. Daarmee kun je het voordeel beoordelen zonder alleen op een architectuurdiagram te vertrouwen.

Microsoft Azure Architecture: Anti-Corruption Layer ↗

Plan verbeterwerk met een toetsbaar eindpunt

Verbind een verbeteropdracht aan een resultaat dat iemand kan beoordelen: een tweede ontwikkelaar kan de testomgeving starten, een fout kan via een referentie worden teruggevonden of een wijziging kan zonder aanpassing van drie andere modules worden uitgevoerd. Leg daarbij vast welke vergelijking passend is. Niet iedere verbetering levert onmiddellijk een sneller scherm op.

Spreek ook af wat de opdracht niet omvat. Een gerichte oplossing voor configuratiebeheer hoeft niet tegelijk de volledige infrastructuur te vervangen. Reserveer ruimte voor gevonden afhankelijkheden en maak een besluitmoment zichtbaar wanneer die de scope veranderen. Zo kan een team waardevolle kleine stappen zetten zonder technische schuld als een onbegrensde onderhoudsrekening te behandelen.

Herzie de agenda wanneer het product verandert

Een schuldenregister moet kunnen veranderen. Als een functie wordt uitgezet, kan een bijbehorend verbeterpunt vervallen. Als een nieuwe klantgroep het systeem anders gebruikt, kan een eerder beperkt risico belangrijker worden. Plan daarom een herbeoordeling rond relevante productwijzigingen en echte incidenten, in plaats van automatisch iedere oude notitie te blijven uitvoeren.

Bewaar de reden waarom een onderwerp is uitgesteld of afgerond. Dat voorkomt dat een volgende ontwikkelaar dezelfde discussie opnieuw moet voeren. Vraag ook of het oorspronkelijke probleem werkelijk minder vaak of minder ernstig voorkomt. Een technisch afgeronde taak is geen bewijs van zakelijke verbetering. Die koppeling blijft de verantwoordelijkheid van ontwikkelaar en proceseigenaar samen.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

• Legacy Software Moderniseren ↗
• Software Audit ↗

Vragen over dit onderwerp

Verder met een aansluitende vraag