Tekninen velka

Tekninen velka on sellaisten toteutusvalintojen kertyneet kustannukset, jotka olivat tuolloin tarkoituksenmukaisia, mutta jotka tekevät tulevista muutoksista hitaampia tai riskialttiimpia. Vertauskuvana on Ward Cunninghamin ajatus: lainanotto tulevaa kapasiteettia vastaan ​​toimittaa nopeammin nyt, ja korkoa maksetaan jokaisesta seuraavasta muutoksesta, kunnes velka on maksettu takaisin. Kuten taloudellinen velka, se ei ole lähtökohtaisesti huono asia, ja tärkeä ero on tarkoituksella otetuilla veloilla ja laiminlyönnistä kertyneillä veloilla.

Metaforan arvo piilee siinä, että kompromissista voi keskustella myös ihmisten kanssa, jotka eivät kirjoita koodia. Refaktorointipyynnön muotoileminen velan takaisinmaksuksi viestii jotain, mitä moduulin uudelleenkirjoituspyyntö ei kerro, nimittäin että kustannukset on jo maksettu hitaampana toimituksena ja korkeampina virheprosentteina, ja että kysymys kuuluu, jatketaanko niiden maksamista. Cunninghamin alkuperäinen muotoilu korosti myös, että velka syntyy kasvavasta kuilusta koodin rakenteen ja tiimin nykyisen ongelmanymmärryksen välillä, mikä on laajempi ajatus kuin pelkkä huolimattoman koodin kirjoittaminen määräaikaan mennessä.

Termin alle ryhmitellään useita erillisiä asioita, ja niihin on vastattava erilaisilla tavoilla. Tahallinen velka, joka on otettu tietoisesti todellisen määräajan täyttämiseksi ja jolla on suunnitelma sen käsittelemiseksi, on oikeutettu insinööripäätös. Vahingossa syntyvä velka, joka syntyy, koska tiimin ymmärrys parani suunnittelun jälkeen, on väistämätöntä ja on oppimisen normaali kustannus. Laiminlyöntivelka, joka johtuu poissaolevista testeistä, dokumentoimattomasta käyttäytymisestä ja ylläpitämättömistä riippuvuuksista, kertyy hiljaa ja on kallein luokka, koska se tekee jokaisesta muutoksesta riskialttiimman. Erityisesti vanhentuneet riippuvuudet aiheuttavat turvallisuusriskejä pelkän haitan sijaan.

Oireet näkyvät toimitusmittareissa ennen kuin ne näkyvät koodissa. Samankaltaisen työn arvioiden kasvu, kapasiteetin kasvava osuus vikoihin, haluttomuus koskea tiettyihin alueisiin ja muutokset yhdessä paikassa, jotka rikkovat toisiinsa liittymättömiä asioita, ovat kaikki merkkejä siitä, että korkomaksusta on tullut huomattava. Tiimit raportoivat usein näistä oireista kapasiteettiongelmina ja pyytävät lisää ihmisiä, mikä yleensä pahentaa tilannetta lyhyellä aikavälillä.

Sen hallinta edellyttää, että työ on näkyvissä samassa suunnitteluprosessissa kuin kaikki muukin. Erillisellä listalla olevaa velkaa, jota käsitellään vain silloin, kun ylimääräistä kapasiteettia on, ei koskaan käsitellä, koska ylimääräistä kapasiteettia ei ole koskaan. Kiinteän osan kohdentaminen kustakin syklistä siihen tai korjaavien toimenpiteiden liittäminen muuttuvien alueiden erityistyöhön ovat kaksi lähestymistapaa, jotka selviävät kaupallisesta paineesta. Vaihtoehto, säännölliset suuret uudelleenkirjoitukset, on yleensä oire työn lykkäämisestä liian kauan ja sisältää paljon enemmän riskejä kuin asteittaiset parannukset.

Korjaavien toimenpiteiden viestiminen toimii paremmin toteutustavoilla kuin teknisillä näkökulmilla. Toteamalla, että tietyn alueen muuttuminen kestää nyt kolme kertaa kauemmin kuin vastaavilla alueilla, viimeaikaisesta työstä saatujen todisteiden perusteella ongelma yhdistetään johonkin ei-teknisille sidosryhmille jo tärkeään asiaan, kun taas arkkitehtuuristen huolenaiheiden kuvaaminen ei tee niin. Kun velkaan liittyy riskiä kustannusten sijaan, kuten ylläpitämättömien riippuvuuksien tai kriittisten polkujen testikattavuuden puuttumisen tapauksessa, sen kuvaaminen altistumisena todennäköisyydellä ja vaikutuksella on tehokkaampaa kuin sen kuvaaminen laadun näkökulmasta. Molemmissa tapauksissa jatkuvien kustannusten kvantifiointi muuntaa tekniset mieltymykset liiketoimintatapaukseksi, joka voi kilpailla ominaisuustyön kanssa kapasiteetista.

Kaikkea velkaa ei pidä maksaa takaisin. Koodi, joka toimii, muuttuu harvoin eikä aiheuta ongelmia, voi pysyä sellaisenaan ulkonäöstä riippumatta, eikä sen parantamiseen käytetty työ tuota mitään tuottoa. Taloudellisesti järkevä lähestymistapa keskittää korjaavat toimet paikkoihin, joissa muutokset ovat yleisiä ja joissa korkoa siis todella maksetaan. Tämän kompromissin näkyväksi tekeminen ja sille eksplisiittisen kapasiteetin varaaminen suunnittelussa on normaali osa sitä, miten tuotekehitys vuorovaikutus on jäsenneltyä, ja se kuuluu etenemissuunnitelmakeskusteluun tuotestudio sen sijaan, että sitä käsiteltäisiin tuotekeskustelun ulkopuolisena teknisenä asiana.