Hantera teknisk skuld med DX och AI

Varje företag, stort och smått, oroar sig för teknisk skuld. Gartner uppskattar att cirka 40% av infrastruktursystem har detta problem. I en undersökning av CIO:er av McKinsey uppgav nästan en tredjedel att över 20% av deras budget för nya produkter gick till att lösa problem relaterade till teknisk skuld. Men till skillnad från vad många tror är detta inte bara ett kodningsproblem, utan också ett utvecklarupplevelseproblem (DX). Eftersom när utvecklare måste arbeta med otillräcklig arkitektur, föråldrad verktygslåda och undermåliga utvecklingsflöden, lider produktivitet, prestanda och moral.

Att prioritera teknisk skuld med utvecklaren i åtanke, fokusera på hur de närmar sig arbetet, vilka verktyg de använder och de karriärframsteg de kan göra, hjälper team att fokusera och leverera snabbare. Detta är varför företag hanterar teknisk skuld på ett annat sätt, driven av DX och en ökad fokus på AI-drivna verktyg.

Förespråka DX

Sättet utvecklare ofta introduceras lämnar mycket att önska. Det kan ta flera veckor för någon att börja bidra till ett projekt. När de slutligen har kunnat lägga till små funktioner eller korrigeringar, är det inte ovanligt att se den kontinuerliga integreringstjänsten (CI) misslyckas på grund av något som inte har med de ändringar de har arbetat med att göra. Detta är i princip testsviten som misslyckas på grund av kvalitetsproblem, och utvecklaren har inte skickat in några ändringar för att göra testsviten misslyckas. Det är en ostabil, dåligt skriven test som bara fungerar 90% av tiden. Det befintliga teamet är förmodligen ok med det – det bromsar bara processerna – men verktygen kan vara föråldrade och demoraliserande för alla utanför organisationen.

Detta är bara ett exempel på många som hindrar rätt DX. Ett sätt att förhindra detta är att ha en utsedd champion i ditt software engineering- och utvecklingsteam. Många små organisationer har inte en DX-ledare, men stora, framgångsrika organisationer har det. Dessa proffs håller koll på saker som hur lång tid det tar för en ny utvecklare att ställa in en miljö. Och om två veckor är för länge, så figurerar de ut hur man kan halvera den tiden.

Det finns verktyg där ute för att hjälpa till, som CircleCI, med infödda funktioner som spårar testsvitens ostabilitet. Vad som behövs är någon som tar ledningen och stoppar efter varje sprint för att hantera några av de ändringar som kommer att göra koden lättare att underhålla och arbeta med i framtiden. Det handlar om att ha en ledare som är intresserad av att göra DX bättre. För att göra det möjligt, leta efter en senioringenjör, åtföljd av en relativt ny personal som kan ge feedback på möjliga luckor.

Även IDC förväntar sig att den AI-drivna programvarutestautomatiseringsmarknaden kommer att fortsätta växa med en CAGR på 31,2% till 2027, så se till att du använder den tekniken till fullo.

Mätetal och varningssignaler

Det finns många mätetal du kan spåra när du utvärderar hur teknisk skuld påverkar ditt team. Några grundläggande är “tid att fixa” eller “tid till funktion”. Låt oss säga att du märker en bugg och vet hur du ska fixa den. Några verktyg kan spåra den tid som spenderas från kodskrivning till produktion. Till exempel skulle du kunna se att en mycket liten korrigering tog två arbetsdagar att fixa och leverera, när ditt team behöver kunna göra det på några timmar. Du kan också spåra förhållanden, som antalet buggfixar jämfört med antalet funktioner som slutförts.

Det finns också sätt att identifiera när moralproblem påverkar ditt teams prestanda. DX-ledare kan köra undersökningar kvartalsvis för att bestämma hur nöjd en utvecklare är med att arbeta på ett projekt eller en del av det. De kan borra ner och fråga om specifika områden som CI-processen. Och du kan alltid spåra personalomsättning eller omsättning i ditt team. Om du märker att människor ständigt lämnar, kan de känna att deras problem inte hörs.

Verktyg med AI

Uppkomsten av AI-verktyg ska göra utvecklare och ingenjörer mer produktiva och produkter levereras snabbare, men teknisk skuld bromsar detta. Låt oss säga att du använder ett verktyg som GitHub eller Copilot för att hjälpa till med kodändringar, sedan skickar du en pull-begäran och CI tar några timmar att komma tillbaka till dig. Under tiden, arbetar en utvecklare på något annat? Kollar e-post? Det är en kontextväxling och en produktivitetsdödare.

Utvecklare vill arbeta på produkter där de kan fokusera på kod. Verktygen är där för att hjälpa dem att komma till produktion, inte vara en konstant vägspärr. AI kan spara tid, men det är upp till ingenjörsteam att definiera sina egna standarder för acceptabel komplexitet. För att göra detta, se till först att all kod som läggs till i din huvudgren har en acceptabel nivå av teknisk skuld. Innan dess, ha en öppen diskussion och få köp-in från ingenjörsteamet på den acceptabla tröskeln för teknisk skuld och kodkvalitet. Se till att alla vet att att gå över den märken kräver omedelbar åtgärd. När du har definierat dessa standarder, kommer AI in i spel.

Det finns ett fall för AI-agenter med ingenjörer som agerar som orkestratörer. En undersökning av Capgemini av 1 100 chefer på stora företag har avslöjat att 82% planerar att integrera AI-agenter under de kommande tre åren, och de har redan påverkat framtiden för arbete. Du kanske tittar på en bugg rapport och ser att den är tillräckligt liten för att en AI-agent ska kunna hantera den från början till kodgranskning, vilket sparar din team tid och frigör dem att hantera mer komplexa arbetsuppgifter. Men ibland, när vi blint följer dessa verktyg, finns det avvägningar som AI kämpar för att överväga.

Då blir en mänsklig åsikt den avgörande faktorn.

Justera teknisk skuld med mål

Hur justerar du teknisk skuldminskning med mål du försöker uppnå eller mätbara resultat? Det handlar om acceptabel teknisk skuld, och ibland i verksamheten måste du leverera snabbt. Du kan göra det med vetskapen om att en produkt inte skalas, och det kan finnas prestandaproblem med tiden. Ofta gör en utvecklare en anteckning om att komma tillbaka till det senare, när det finns tid att hantera dessa problem, men det händer sällan. Och när denna dåliga kultur tar över, där du ständigt måste leverera imorgon, blir effekten av skulden alldeles för tydlig.

Detta är förståeligt för en startup, men inte för ett företag som har varit igång i ett decennium. Du behöver börja skifta din kultur tidigt och aktivt för att hantera teknisk skuld; annars kommer du att spendera en massa pengar på att fixa produktionsbuggar eller oroa dig för säkerhet och regelefterlevnad.

Till slut finns det mätetal som hjälper till att kommunicera värdet av att omstrukturera eller betala av teknisk skuld till intressenter. Tiden kunde vara en, från början till produktion, eller från att öppna en pull-begäran till att slå samman och leverera den till produktion. En annan är medel tid till reparation (MTTR). I det fallet kan du ha hittat en bugg eller en trasig byggnad, och du mäter hur lång tid det tar för ditt team att fixa det. Du kunde spåra antalet buggar du har i produktion också. Om du ser att antalet ökar, kan det finnas ett problem relaterat till teknisk skuld.

Teknisk skuld med ränta

Varje organisation kan ägna några timmar varje vecka åt att förbättra sin DX för att hjälpa till att minska teknisk skuld. Om inte, kan du betala för det senare, troligen genom långsam prestanda, en betydande bromsning i utvecklingshastighet eller säkerhetsproblem. Till exempel kan ditt team av ingenjörer och utvecklare ha skjutit upp uppgraderingar av Ruby on Rails i ett decennium. Plötsligt ökar ett projektets kostnad med en halv miljon dollar, eftersom versionen av Ruby är fyra generationer bakom, vilket lämnar dig med en massa kod och föråldrade beroenden.

Om du hade uppgraderat gradvis, skulle du inte vara i den här situationen. Så stöd ditt softwareutvecklingsteam och betala medan du går. Annars kommer den tekniska skulden att komma tillbaka och hämta dig, med ränta.