Het beheren van technische schuld 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 budget voor nieuwe producten naar het oplossen van problemen met technische schuld ging. Maar in tegenstelling tot wat veel mensen denken, is dit geen enkel een coderingsprobleem; het is ook een ontwikkelaarservaring (DX)-probleem. Omdat wanneer ontwikkelaars moeten werken met onvoldoende architectuur, verouderde tooling en ondermaatse ontwikkelingsworkflows, de productiviteit, prestaties en moreel lijden.

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èremogelijkheden ze kunnen krijgen, 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 geïntroduceerd, laat veel te wensen over. Het kan een paar weken duren voordat iemand kan beginnen met bijdragen aan een project. Zodra ze eindelijk kleine functies of patches hebben toegevoegd, is het niet ongebruikelijk om te zien dat de continue integratieservice (CI) faalt 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 een voorbeeld van de vele dingen 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 bij hoe lang het duurt voordat een nieuwe ontwikkelaar een omgeving heeft ingesteld. En als twee weken te lang is, bedenken ze 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 na elke sprint stopt om enkele van de wijzigingen aan te pakken die de code gemakkelijker te onderhouden en te werken maken in de toekomst. Het komt neer op het hebben van een leider die geïnteresseerd is in het verbeteren van de DX. Om dit 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 zal blijven groeiende met een CAGR van 31,2% tot 2027, dus zorg ervoor dat u deze technologie maximaal benut.

Metric en waarschuwingsignalen

Er zijn veel metrics die u kunt bijhouden bij het evalueren van de impact van technische schuld op uw team. Enkele basismetrics zijn “tijd tot reparatie” of “tijd tot functie”. Laten we zeggen dat u een bug opmerkt en weet hoe u deze kunt repareren. Sommige tools kunnen de tijd bijhouden vanaf het schrijven van code tot productie. U kunt bijvoorbeeld zien dat een zeer kleine patch twee werkdagen nodig had 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 identificeren wanneer morele problemen de prestaties van uw team beïnvloeden. DX-leiders kunnen elk 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 steeds vertrekken, kunnen ze het gevoel hebben dat hun zorgen niet worden gehoord.

Tooling met AI

De opkomst van AI-tooling zou ontwikkelaars en ingenieurs productiever moeten maken en producten sneller moeten laten verzenden, 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 nodig heeft om terug te komen. Ondertussen, werkt een ontwikkelaar aan iets anders? Checkt hij e-mails? Het is een contextwisseling en een productiviteitsdoder.

Ontwikkelaars willen werken aan producten waar ze zich alleen op code kunnen concentreren. De tooling is er om te helpen bij het naar productie brengen, niet om een constante belemmering te vormen. 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 eerst ervoor zorgen dat elke code die aan uw hoofdbranch 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 markering onmiddellijke herstelwerkzaamheden vereist. Zodra u deze normen heeft gedefinieerd, komt AI in beeld.

Er is een geval voor AI-agents met ingenieurs die als orchestrators optreden. Een enquête van Capgemini onder 1.100 executives bij grote ondernemingen heeft aangetoond dat 82% van plan zijn om AI-agents te integreren in de komende drie jaar, en ze hebben 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 de codereview te behandelen, waardoor uw team tijd bespaart en in staat is om complexere werkzaamheden uit te voeren. 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 verzenden. U kunt dit doen wetende dat een product niet schaalbaar is en er mogelijk prestatieproblemen optreden na verloop van tijd. Vaak zal een ontwikkelaar een notitie maken om later terug te komen op deze kwestie, wanneer er tijd is om deze problemen aan te pakken, maar dit gebeurt zelden. En wanneer deze slechte cultuur de overhand krijgt, waarin u constant moet verzenden voor morgen, 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 verschuiven van uw cultuur vroeg en actief om technische schuld te beheren; anders zult u veel geld uitgeven aan het oplossen van productiebugs of zich zorgen maken over beveiliging en naleving.

Tenslotte zijn er metrics om de waarde van refactoring of het afbetalen van technische schuld aan stakeholders te communiceren. Tijd kan er een van 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 tot reparatie (MTTR). In dit geval hebt u mogelijk een bug gevonden of een gebroken build, en meet u 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 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 u dat niet doet, moet u mogelijk later betalen, waarschijnlijk door slechte prestaties, een aanzienlijke vertraging in de ontwikkelingsvelocity of beveiligingsproblemen. Uw team van ingenieurs en ontwikkelaars kan bijvoorbeeld tien jaar uitgesteld hebben met het upgraden van Ruby on Rails. 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 heeft.

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