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 door McKinsey gaf bijna een derde aan dat meer dan 20% van hun budget voor nieuwe producten ging naar het oplossen van problemen met technische schuld. Maar in tegenstelling tot wat velen denken, is dit niet alleen een codeprobleem; het is ook een probleem van de ontwikkelaarservaring (DX). Want wanneer ontwikkelaars moeten werken met ontoereikende architectuur, verouderde tooling en ondermaatse ontwikkelworkflows, lijden de productiviteit, prestaties en het moreel eronder.

Door technische schuld te prioriteren met de ontwikkelaar in gedachten, en te focussen op hoe ze hun werk aanpakken, welke tools ze gebruiken en welke carrièremogelijkheden ze kunnen creëren, kunnen teams zich beter concentreren en sneller leveren. Daarom verandert de manier waarop bedrijven omgaan met technische schuld, gedreven door DX en een toenemende focus op AI-gestuurde tooling.

DX-kampioen worden

De manier waarop ontwikkelaars vaak worden onboarded laat te wensen over. Het kan een paar weken duren voordat iemand begint bij te dragen aan een project. Zodra ze eindelijk kleine functies of patches hebben kunnen toevoegen, is het niet ongebruikelijk dat de CI-service (Continuous Integration) faalt door iets dat volledig losstaat van de wijzigingen waaraan ze hebben gewerkt. Dit komt in feite neer op een testsuite die faalt door problemen met de kwaliteit, en de ontwikkelaar heeft geen wijzigingen ingediend om de testsuite te laten crashen. Het is een onbetrouwbare, slecht geschreven test die slechts 90% van de tijd werkt. Het bestaande team vindt het waarschijnlijk prima – het vertraagt ​​alleen de processen – maar de tooling is mogelijk verouderd en demotiverend voor iedereen buiten de organisatie.

Dit is een van de vele voorbeelden die de juiste DX in de weg staan. Een manier om dit te voorkomen, is door een aangewezen ambassadeur in je software engineering- en ontwikkelteam te hebben. Veel kleine organisaties hebben geen DX-leider, maar grote, succesvolle organisaties wel. Deze professionals houden zaken bij, zoals hoe lang het een nieuwe ontwikkelaar kost om een ​​omgeving op te zetten. En als twee weken te lang is, bedenken ze hoe ze die tijd kunnen halveren.

Er is tooling beschikbaar die hierbij kan helpen, zoals CircleCI, met native functies die de kwetsbaarheid van een testsuite in de gaten houden. Wat nodig is, is iemand die het voortouw neemt en na elke sprint de tijd neemt om een ​​aantal wijzigingen aan te brengen die de code in de toekomst gemakkelijker te onderhouden en te gebruiken maken. Het komt erop neer dat je een leider hebt die geïnteresseerd is in het verbeteren van de DX. Om dat te realiseren, zoek je een senior engineer, vergezeld door een relatief nieuwe medewerker die feedback kan geven over mogelijke tekortkomingen.

IDC verwacht ook dat de markt voor AI-aangedreven softwaretestautomatisering zal blijven groeien tot 31.2 met een CAGR van 2027% groeienZorg er dus voor dat u deze technologie optimaal benut.

Metrieken en waarschuwingssignalen

Er zijn veel statistieken die je kunt bijhouden om te evalueren hoe technische schuld je team beïnvloedt. Enkele basisgegevens zijn 'tijd om te repareren' of 'tijd om een ​​feature te ontwikkelen'. Stel dat je een bug ontdekt en weet hoe je die moet oplossen. Sommige tools kunnen de tijd bijhouden die is besteed van het schrijven van de code tot aan de productie. Zo kun je bijvoorbeeld zien dat een zeer kleine patch twee werkdagen duurde om te repareren en te leveren, terwijl je team dat in uren moet kunnen doen. Je kunt ook ratio's bijhouden, zoals het aantal bugfixes ten opzichte van het aantal voltooide features.

Er zijn ook manieren om te identificeren wanneer morele problemen de prestaties van je team beïnvloeden. DX-leiders kunnen elk kwartaal enquêtes houden om te bepalen hoe tevreden een ontwikkelaar is met een project of een onderdeel daarvan. Ze kunnen inzoomen en vragen stellen over specifieke gebieden, zoals het CI-proces. En je kunt altijd het verloop of de turnaround in je team volgen. Als je merkt dat mensen steeds weggaan, kunnen ze het gevoel hebben dat hun zorgen niet gehoord worden.

Werken met AI

De opkomst van AI-tools zou ontwikkelaars en engineers productiever moeten maken en producten sneller moeten leveren, maar technische schuld vertraagt ​​dit proces. Stel dat je een tool als GitHub of Copilot gebruikt om codewijzigingen door te voeren, vervolgens een pull request indient en het een paar uur duurt voordat de CI reageert. Werkt een ontwikkelaar in de tussentijd aan iets anders? Checkt hij of zij zijn of haar e-mail? Het is een contextswitch en een productiviteitskiller.

Ontwikkelaars willen werken aan producten waarbij ze zich alleen op de code hoeven te concentreren. De tooling is er om hen te helpen deze in productie te nemen, niet om een ​​constante blokkade te vormen. AI kan tijd besparen, maar het is aan engineeringteams om hun eigen normen voor acceptabele complexiteit te definiëren. Zorg er daarom eerst voor dat alle code die aan je hoofdbranch wordt toegevoegd een acceptabel niveau van technische schuld heeft. Voer daarvoor een open discussie en zorg ervoor dat het engineeringteam achter de acceptabele drempelwaarde voor technische schuld en codekwaliteit staat. Zorg ervoor dat iedereen weet dat het overschrijden van die drempelwaarde onmiddellijke verbetering vereist. Zodra je die normen hebt gedefinieerd, komt AI om de hoek kijken.

Er valt iets te zeggen voor AI-agenten waarbij engineers als orkestrators fungeren. Uit een enquête van Capgemini onder 1,100 leidinggevenden bij grote ondernemingen is gebleken dat 82% is van plan AI-agenten te integreren in de komende drie jaar, en ze hebben nu al invloed op de toekomst van het werkJe bekijkt misschien een bugrapport en ziet dat het klein genoeg is voor een AI-agent om van begin tot codereview af te handelen, waardoor je team tijd bespaart en meer tijd overhoudt voor complexer werk. Maar soms, wanneer we deze tools blindelings volgen, zijn er afwegingen die AI moeilijk kan maken.

Dan is de mening van een mens doorslaggevend.

Technische schuld afstemmen op doelen

Hoe stem je technische schuldreductie af op de doelen die je probeert te bereiken of op meetbare resultaten? Het komt neer op acceptabele technische schuld, en soms moet je in het bedrijfsleven snel leveren. Je kunt dit doen wetende dat een product niet schaalbaar is en dat er na verloop van tijd prestatieproblemen kunnen ontstaan. Vaak maakt een ontwikkelaar een aantekening om hier later op terug te komen, wanneer er tijd is om deze problemen aan te pakken, maar dat gebeurt zelden. En wanneer deze slechte cultuur de overhand neemt, waarin je constant morgen moet leveren, wordt de impact van de schuld overduidelijk.

Dit is begrijpelijk voor een startup, maar niet voor een bedrijf dat al tien jaar actief is. Je moet vroeg en actief beginnen met het veranderen van je bedrijfscultuur om technische schulden te beheren; anders geef je bakken met geld uit aan het oplossen van productiefouten of aan zorgen over beveiliging en compliance.

Tot slot zijn er statistieken die helpen bij het communiceren van de waarde van refactoring of het afbetalen van technische schuld aan stakeholders. Tijd kan er bijvoorbeeld één zijn: van concept tot productie, of van het openen van een pull-request tot het samenvoegen en verzenden ervan naar productie. Een andere is de gemiddelde reparatietijd (MTTR). In dit geval heb je mogelijk een bug of een defecte build gevonden en meet je hoe lang het je team kost om deze te verhelpen. Je kunt ook het aantal bugs in productie bijhouden. Als je dat getal ziet stijgen, 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 zo de technische schuld te verminderen. Zo niet, dan betaalt u daar later mogelijk de prijs voor, waarschijnlijk door trage prestaties, een aanzienlijke vertraging in de ontwikkelsnelheid of beveiligingsproblemen. Uw team van engineers en ontwikkelaars kan bijvoorbeeld al tien jaar lang upgrades naar Ruby on Rails uitstellen. Plotseling stijgen de projectkosten met een half miljoen dollar omdat de Ruby-versie vier generaties achterloopt, waardoor u met een enorme hoeveelheid code en verouderde afhankelijkheden blijft zitten.

Als je geleidelijk had geüpgraded, zou je niet in deze situatie zijn beland. Ondersteun daarom je softwareontwikkelingsteam en betaal per gebruik. Anders komt die technische schuld je met rente achtervolgen.