Behandling av teknisk gjeld med DX og AI

Hvert selskap, stort og smått, bekymrer seg for teknisk gjeld. Gartner estimerer at omtrent 40% av infrastruktursystemer har dette problemet. I en undersøkelse av CIO-er av McKinsey, følte nesten en tredjedel at over 20% av deres nye produktbudsjett gikk til å løse problemer relatert til teknisk gjeld. Men i motsetning til hva mange tror, er dette ikke bare et kodeproblem; det er også et utvikleropplevelse (DX)-problem. For når utviklere må jobbe med utilstrekkelig arkitektur, foreldet verktøy og underpar utviklingsprosesser, lider produktivitet, ytelse og moral.

Prioritering av teknisk gjeld med utvikleren i mente, fokus på hvordan de nærmer seg arbeid, hva verktøy de bruker og karriereframgang de kan oppnå, hjelper teamene å fokusere og levere raskere. Dette er hvorfor måten selskaper håndterer teknisk gjeld endrer seg, drevet av DX og en økt fokus på AI-drevet verktøy.

Championing DX

Måten utviklere ofte blir onboardet, lar mye å ønske. Det kan ta noen uker alene for noen å begynne å bidra til et prosjekt. Når de endelig har kunnet legge til små funksjoner eller patches, er det ikke uvanlig å se at den kontinuerlige integrasjonen (CI) tjenesten feiler på grunn av noe helt uavhengig av endringene de har jobbet med. Dette er grunnleggende sett en feil i test suiten på grunn av kvalitetsproblemer, og utvikleren har ikke sendt inn endringer for å gjøre test suiten feil. Det er en ustabil, dårlig skrevet test som bare fungerer 90% av tiden. Den eksisterende teamet er sannsynligvis ok med det – det bare sakter ned prosessene – men verktøyet kan være foreldet og demoraliserende for noen utenfor organisasjonen.

Dette er ett eksempel på mange som hindrer riktig DX. En måte å forhindre dette på er å ha en dedikert champion på ditt softwareingeniør- og utviklingsteam. Mange små organisasjoner har ikke en DX-leder, men store, suksessfulle gjør det. Disse proffene holder øye med ting som hvor lang tid det tar en ny utvikler å sette opp en miljø. Og hvis to uker er for langt, finner de ut hvordan de kan kutte tiden i halvannen.

Det finnes verktøy der ute for å hjelpe, som CircleCI, med native funksjoner som vil spore ustabiliteten i en test suite. Hva som trengs, er noen som tar ledelsen og stopper etter hver sprint for å håndtere noen av endringene som vil gjøre koden lettere å vedlikeholde og jobbe med i fremtiden. Det kommer ned til å ha en leder som er interessert i å gjøre DX bedre. For å gjøre dette, søk etter en senior-ingeniør, ledsaget av en relativt ny medarbeider som kan gi tilbakemelding på mulige hull.

Også, IDC forventer at markedet for AI-drevet programvaretestautomatisering vil fortsette å vokse med en årlig vekstrate på 31,2% frem til 2027, så sikre deg at du utnytter denne teknologien maksimalt.

Mål og advarselstegn

Det finnes mange mål du kan spore når du vurderer hvordan teknisk gjeld påvirker ditt team. Noen grunnleggende er “tid til å fikse” eller “tid til funksjon”. La oss si du oppdager en feil og vet hvordan du kan fikse den. Noen verktøy kan spore tiden fra kode skriving til produksjon. For eksempel, ville du være i stand til å se at en svært liten patch tok to forretningsdager å fikse og levere, når ditt team trenger å kunne gjøre det på timer. Du kan også spore forhold, som antall feilrettinger versus funksjoner fullført.

Det finnes også måter å identifisere når moralproblemer påvirker ditt teams ytelse. DX-ledere kan kjøre undersøkelser kvartalsvis for å bestemme hvor glad en utvikler er med å jobbe på et prosjekt eller en del av det. De kan bore ned og spørre om spesifikke områder som CI-prosessen. Og du kan alltid spore omsetning eller omskiftning i ditt team. Hvis du merker at folk forlater, kan de føle at deres bekymringer ikke blir hørt.

Verktøy med AI

Oppblomstringen av AI-verktøy skal gjøre utviklere og ingeniører mer produktive og produkter skal leveres raskere, men teknisk gjeld sakter dette ned. La oss si du bruker et verktøy som GitHub eller Copilot for å hjelpe med kodeendringer, deretter sender du pull-forespørselen, og CI tar noen timer å komme tilbake til deg. I mellomtiden, jobber en utvikler med noe annet? Sjekker e-post? Det er en kontekstendring og en produktivitetsdreper.

Utviklere ønsker å jobbe på produkter hvor de bare kan fokusere på kode. Verktøyet er der for å hjelpe dem å komme til produksjon, ikke for å være en konstant hindring. AI kan spare tid, men det er opp til ingeniørteamene å definere sine egne standarder for akseptabel kompleksitet. For å gjøre dette, sikre deg først at all kode som legges til hovedgrenen har et akseptabelt nivå av teknisk gjeld. Før det, ha en åpen diskusjon og få innvilelse fra ingeniørteamet på akseptabelt nivå av teknisk gjeld og kodekvalitet. Sikre deg at alle vet at å gå over dette merket krever umiddelbar rettelse. Når du har definert disse standardene, kommer AI inn i bildet.

Det finnes et tilfelle for AI-agenter med ingeniører som fungerer som orkestratorer. En Capgemini-undersøkelse av 1 100 ekskjutiver i store bedrifter har avdekket at 82% planlegger å integrere AI-agenter de neste tre årene, og de har allerede innvirkning på fremtidens arbeid. Du kan se på en feilrapport og se at den er liten nok for en AI-agent å håndtere fra oppstart til kodegjennomgang, og spare ditt team tid og frigjøre dem til å håndtere mer kompleks arbeid. Men noen ganger, når vi blindt følger disse verktøyene, er det kompromisser som AI sliter med å vurdere.

Dette er da et menneskelig syn blir avgjørende.

Justere teknisk gjeld med mål

Hvordan justerer du teknisk gjeldsreduksjon med målene du prøver å oppnå eller målbare resultater? Det går tilbake til akseptabel teknisk gjeld, og noen ganger i forretning, må du levere raskt. Du kan gjøre det med viten om at et produkt ikke skalerer, og det kan være ytelsesproblemer over tid. Ofte vil en utvikler lage en notat om å komme tilbake til dette senere, når det er tid til å håndtere disse problemene, men det skjer sjelden. Og når denne dårlige kulturen tar over, hvor du må levere i morgen, blir effekten av gjelden mer enn tydelig.

Dette er forståelig for en startup, men ikke for et bedrift som har vært i drift i et tiår. Du må begynne å endre kulturen tidlig og aktivt for å håndtere teknisk gjeld; ellers vil du bruke en masse penger på å fikse produksjonsfeil eller bekymre deg for sikkerhet og overholdelse.

Til slutt, finnes det mål som kan hjelpe med å kommunisere verdien av å omstrukturere eller betale ned teknisk gjeld til interessenter. Tid kan være ett, fra oppstart til produksjon, eller fra åpning av en pull-forespørsel til sammenslåing og levering til produksjon. Et annet er gjennomsnittlig tid til reparasjon (MTTR). I dette tilfelle kan du ha funnet en feil eller en feil i byggingen, og du måler hvor lang tid det tar ditt team å fikse det. Du kan også spore antall feil du har i produksjon. Hvis du ser at dette tallet øker, kan det være et problem relatert til teknisk gjeld.

Teknisk gjeld med renter

Hvert organisasjon kan dedikere noen timer hver uke til å forbedre DX for å hjelpe med å redusere teknisk gjeld. Hvis ikke, kan du betale for det senere, sannsynligvis ved langsom ytelse, en betydelig nedgang i utviklingshastighet eller sikkerhetsproblemer. For eksempel, kunne ditt team av ingeniører og utviklere ha utsatt oppgraderinger til Ruby on Rails i et tiår. Plutselig øker prosjektets kostnad med en halv million dollar fordi versjonen av Ruby er fire generasjoner bak, og du blir sittende med en masse kode og foreldede avhengigheter.

Hvis du hadde oppgradert gradvis, ville du ikke vært i denne situasjonen. Støtt derfor ditt softwareutviklingsteam og betal som du går. Ellers vil den tekniske gjelden komme tilbake og hjemsøke deg, med renter.