Teknisk skuld

Teknisk skuld är den ackumulerade kostnaden för implementeringsval som var ändamålsenliga vid den tidpunkten men som gör framtida förändringar långsammare eller mer riskfyllda. Metaforen är Ward Cunninghams: att låna mot framtida kapacitet att leverera tidigare nu, med ränta som betalas för varje efterföljande förändring tills skulden är återbetald. Liksom finansiell skuld är den inte i sig dålig, och den viktiga skillnaden är mellan skuld som tagits medvetet av en anledning och skuld som ackumulerats genom försummelse.

Metaforens värde ligger i att göra avvägningen diskussionsbar med personer som inte skriver kod. Att formulera en omstruktureringsförfrågan som skuldåterbetalning kommunicerar något som en begäran om att skriva om en modul inte gör, nämligen att kostnaden redan betalas, i form av långsammare leverans och högre felfrekvenser, och att frågan är om man ska fortsätta betala den. Cunninghams ursprungliga formulering betonade också att skuld uppstår ur ett växande gap mellan kodens struktur och teamets nuvarande förståelse av problemet, vilket är en bredare idé än att bara skriva slarvig kod under deadline.

Flera olika saker grupperas under termen, och de kräver olika svar. Avsiktlig skuld, som tas medvetet för att möta en verklig deadline med en plan för att åtgärda den, är ett legitimt ingenjörsbeslut. Oavsiktlig skuld, som uppstår på grund av att teamets förståelse förbättrades efter att designen fastställdes, är oundviklig och är den normala kostnaden för lärande. Försummelseskuld, från frånvarande tester, odokumenterat beteende och oupprätthållna beroenden, ackumuleras tyst och är den dyraste kategorin eftersom den gör varje förändring mer riskabel. Föråldrade beroenden i synnerhet medför säkerhetsrisk snarare än bara olägenhet.

Symtomen syns i leveransmått innan de syns i kod. Växande uppskattningar för liknande arbete, en ökande andel kapacitet som läggs på defekter, ovilja att röra vid specifika områden och förändringar på ett ställe som förstör orelaterade saker är alla indikationer på att räntebetalningen har blivit betydande. Team rapporterar ofta dessa symtom som kapacitetsproblem och begär fler personer, vilket vanligtvis förvärrar situationen på kort sikt.

Att hantera det kräver att arbetet syns i samma planeringsprocess som allt annat. Skulder som hålls på en separat lista och som endast åtgärdas när det finns ledig kapacitet åtgärdas aldrig, eftersom det aldrig finns ledig kapacitet. Att allokera en fast andel av varje cykel till den, eller att koppla åtgärdande till funktionsarbete inom de områden som ändras, är de två metoder som överlever kontakt med kommersiellt tryck. Alternativet, periodiska stora omskrivningar, är vanligtvis ett symptom på att arbetet har skjutits upp för länge och medför mycket större risk än stegvisa förbättringar.

Att kommunicera argumenten för åtgärdande fungerar bättre i leveranstermer än i tekniska termer. Att konstatera att ett visst område nu tar tre gånger längre tid att förändra än jämförbara områden, med bevis från senare arbete, kopplar problemet till något som icke-tekniska intressenter redan bryr sig om, medan beskrivningen av arkitektoniska problem inte gör det. Där skulden medför risk snarare än kostnad, som med oupprätthållna beroenden eller avsaknad av testtäckning på kritiska vägar, är det mer effektivt att formulera den som exponering med en sannolikhet och en påverkan än att formulera den som kvalitet. I båda fallen är det att kvantifiera den löpande kostnaden som omvandlar en teknisk preferens till ett affärsmässigt fall som kan konkurrera med funktionsarbete om kapacitet.

All skuld bör inte betalas tillbaka. Kod som fungerar, sällan ändras och inte orsakar några problem kan förbli som den är oavsett hur den ser ut, och ansträngningar som läggs på att förbättra den ger ingen avkastning. Den ekonomiskt sunda metoden koncentrerar åtgärden där förändringar sker ofta och där räntan därför faktiskt betalas. Att synliggöra den avvägningen och reservera uttrycklig kapacitet för den i planeringen är en normal del av hur en ... produktutveckling engagemanget är strukturerat och det hör hemma i färdplansdiskussionen inom en produktstudio snarare än att behandlas som en teknisk fråga utanför produktdiskussionen.