Technische schuld beheren met DX en AI

Elk bedrijf, groot en klein, maakt zich zorgen over technische schuld. Gartner schat dat ongeveer 40% van de infrastructuursystemen dit probleem heeft. In een enquête onder CIO’s van McKinsey voelde bijna een derde dat meer dan 20% van hun nieuwe productbudget naar het oplossen van problemen met betrekking tot technische schuld ging. Maar in tegenstelling tot wat veel mensen denken, is dit geen enkel coderingsprobleem; het is ook een ontwikkelaarservaring (DX)-probleem. Omdat ontwikkelaars moeten werken met onvoldoende architectuur, verouderde tooling en ondermaatse ontwikkelingsworkflows, lijden productiviteit, prestaties en moreel.

Het prioriteren van technische schuld met de ontwikkelaar in gedachten, met focus op hoe ze hun werk benaderen, welke tools ze gebruiken en welke carrièrestappen ze kunnen zetten, helpt teams om zich te concentreren en sneller te leveren. Dit is waarom de manier waarop bedrijven technische schuld beheren, verandert, aangedreven door DX en een grotere focus op AI-gebaseerde tooling.

DX bevorderen

De manier waarop ontwikkelaars vaak worden ingeschakeld, laat veel te wensen over. Het kan een paar weken duren voordat iemand bijdraagt aan een project. Zodra ze eindelijk kleine functies of patches hebben toegevoegd, is het niet ongebruikelijk om de continue integratie (CI) service te zien falen vanwege iets dat helemaal niet gerelateerd is aan de wijzigingen die ze hebben aangebracht. Dit is eigenlijk het testpakket dat faalt vanwege kwaliteitsproblemen, en de ontwikkelaar heeft geen wijzigingen aangebracht om het testpakket te breken. Het is een onbetrouwbaar, slecht geschreven test dat alleen 90% van de tijd werkt. Het bestaande team is waarschijnlijk oké met het feit dat het processen vertraagt – maar de tooling kan verouderd en demoraliserend zijn voor iedereen buiten de organisatie.

Dit is slechts één voorbeeld van de vele die de juiste DX belemmeren. Een manier om dit te voorkomen is om een aangewezen kampioen te hebben in uw software-engineering- en ontwikkelteam. Veel kleine organisaties hebben geen DX-leider, maar grote, succesvolle organisaties wel. Deze professionals houden bijvoorbeeld bij hoe lang het duurt voordat een nieuwe ontwikkelaar een omgeving heeft ingesteld. En als twee weken te lang is, zoeken ze uit hoe ze die tijd kunnen halveren.

Er is tooling beschikbaar om te helpen, zoals CircleCI, met native functies die de onbetrouwbaarheid van een testpakket bijhouden. Wat nodig is, is iemand die de leiding neemt en stopt na elke sprint om enkele van de wijzigingen aan te pakken die de code gemakkelijker zullen maken om in de toekomst te onderhouden en mee te werken. Het komt neer op het hebben van een leider die geïnteresseerd is in het verbeteren van de DX. Om dat te laten gebeuren, zoekt u naar een senior-level engineer, vergezeld van een relatief nieuwe medewerker die feedback kan geven over mogelijke lacunes.

Ook verwacht IDC dat de AI-gebaseerde softwaretestautomatiseringsmarkt tot 2027 zal blijven groeien met een CAGR van 31,2%, dus zorg ervoor dat u deze technologie maximaal benut.

Metingen en waarschuwingsignalen

Er zijn veel metingen die u kunt uitvoeren wanneer u beoordeelt hoe technische schuld uw team beïnvloedt. Enkele basismetingen zijn “tijd om te repareren” of “tijd om een functie te implementeren”. Laten we zeggen dat u een bug opmerkt en weet hoe u deze kunt repareren. Sommige tools kunnen de tijd bijhouden die wordt besteed vanaf het schrijven van code tot productie. U kunt bijvoorbeeld zien dat een zeer kleine patch twee werkdagen duurde om te repareren en te verzenden, terwijl uw team in staat moet zijn om dit in uren te doen. U kunt ook verhoudingen bijhouden, zoals het aantal bugfixes versus de voltooide functies.

Er zijn ook manieren om te bepalen wanneer morele problemen de prestaties van uw team beïnvloeden. DX-leiders kunnen elke kwartaal enquêtes uitvoeren om te bepalen hoe gelukkig een ontwikkelaar is met het werken aan een project of een deel ervan. Ze kunnen dieper graven en vragen stellen over specifieke gebieden zoals het CI-proces. En u kunt altijd de verloop of omloop in uw team bijhouden. Als u merkt dat mensen blijven vertrekken, kunnen ze het gevoel hebben dat hun zorgen niet worden gehoord.

Werken met AI

De opkomst van AI-tooling moet ontwikkelaars en ingenieurs productiever maken en producten sneller leveren, maar technische schuld vertraagt dit. Laten we zeggen dat u een tool zoals GitHub of Copilot gebruikt om te helpen bij codewijzigingen, vervolgens een pull-verzoek indient en CI een paar uur duurt om terug te komen. Ondertussen, werkt een ontwikkelaar aan iets anders? Controleert hij e-mails? Het is een contextwisseling en een productiviteitsmoordenaar.

Ontwikkelaars willen werken aan producten waar ze zich alleen op code kunnen concentreren. De tooling is er om hen te helpen om het naar productie te krijgen, niet om een constante belemmering te zijn. AI kan tijd besparen, maar het is aan de engineeringteams om hun eigen normen voor aanvaardbare complexiteit te definiëren. Om dit te doen, moet u ervoor zorgen dat elke code die aan uw hoofdvertakking wordt toegevoegd, een aanvaardbaar niveau van technische schuld heeft. Voordat u dat doet, moet u een open discussie voeren en akkoord krijgen van het engineeringteam over het aanvaardbare drempel van technische schuld en codekwaliteit. Zorg ervoor dat iedereen weet dat het overschrijden van die drempel onmiddellijke herstel vereist. Zodra u die normen heeft gedefinieerd, komt AI in beeld.

Er is een geval voor AI-agents met ingenieurs die als orkestrators optreden. Een onderzoek van Capgemini onder 1.100 executives van grote ondernemingen heeft aangetoond dat 82% van plan zijn om AI-agents in de komende drie jaar te integreren, en ze hebben nu al impact op de toekomst van werk. U kunt naar een bugrapport kijken en zien dat het klein genoeg is voor een AI-agent om vanaf het begin tot codebeoordeling te behandelen, waardoor uw team tijd bespaart en in staat is om complexer werk te doen. Echter, soms, wanneer we deze tools blindelings volgen, zijn er compromissen die AI niet kan overwegen.

Dat is wanneer een menselijke mening de beslissende factor wordt.

Technische schuld uitlijnen met doelen

Hoe kunt u technische schuldreductie uitlijnen met de doelen die u probeert te bereiken of meetbare resultaten? Het gaat terug naar aanvaardbare technische schuld, en soms in het bedrijfsleven moet u snel leveren. U kunt dit doen met de wetenschap dat een product niet schaalbaar is en dat er mogelijk prestatieproblemen zijn na verloop van tijd. Vaak zal een ontwikkelaar een notitie maken om later terug te komen op deze problemen, wanneer er tijd is om ze aan te pakken, maar dat gebeurt zelden. En wanneer deze slechte cultuur de overhand krijgt, waarin u constant moet leveren, wordt de impact van de schuld overvloedig duidelijk.

Dit is begrijpelijk voor een startup, maar niet voor een bedrijf dat al tien jaar bestaat. U moet beginnen met het veranderen van uw cultuur om technische schuld te beheren; anders zult u veel geld uitgeven aan het oplossen van productiefouten of zich zorgen maken over beveiliging en naleving.

Ten slotte zijn er metingen om de waarde van het refactoren of afbetalen van technische schuld aan stakeholders te communiceren. Tijd kan er een zijn, vanaf het begin tot productie, of vanaf het openen van een pull-verzoek tot samenvoegen en verzenden naar productie. Een andere is de gemiddelde tijd om te herstellen (MTTR). In dit geval kunt u een bug of een gebroken build hebben gevonden en meten hoe lang het duurt voordat uw team het heeft gerepareerd. U kunt ook het aantal bugs in productie bijhouden. Als u ziet dat dit aantal toeneemt, kan er een probleem zijn met betrekking tot technische schuld.

Technische schuld met rente

Elke organisatie kan een paar uur per week besteden aan het verbeteren van de DX om technische schuld te verminderen. Als dat niet gebeurt, moet u mogelijk later betalen, waarschijnlijk door langzame prestaties, een aanzienlijke vertraging in de ontwikkelingsvelocity of beveiligingsproblemen. Uw team van ingenieurs en ontwikkelaars kan bijvoorbeeld tien jaar lang uitstel van upgrades van Ruby on Rails hebben uitgesteld. Plotseling is het projectkosten met een half miljoen dollar toegenomen omdat de versie van Ruby vier generaties achterloopt, waardoor u een massa code en verouderde afhankelijkheden overhoudt.

Als u geleidelijk had geüpgraded, zou u niet in deze situatie zitten. Ondersteun dus uw software-ontwikkelteam en betaal zoals u gaat. Anders zal die technische schuld u later komen achtervolgen, met rente.