(Martin Fowler segít a témában tisztán látni.)

Képzeljük el a következőt: egy meglévő rendszerhez hozzá kell adni egy új dolgot. Ilyenkor általában két irányban indulhatunk el. Az egyik megoldást gyorsan tető alá tudjuk hozni és a végeredményül kapott kód meglehetősen rendetlen lenne. Így biztosak vagyunk benne, hogy nehezen karbantartható kódot eredményezne. A másik megoldás egy tiszta tervezés eredményéül kapott jól áttekinthető kód és az első megoldásnál jelentősen tovább tart megvalósítani.

A műszaki adósság egy csodálatos hasonlat, szerzője Ward Cunningham (Itt egy videó is). Segítségével új nézőponton keresztül gondolkodhatunk erről a problémáról. Ebben a hasonlatban tehát elvégezzük a tűzoltást olyan gyorsan, ahogy tudjuk, és ezzel műszaki adósságot veszünk a nyakunkba. És bizony ez az adósság bizonyos szempontból hasonlóan viselkedik, mint egy pénzügyi kölcsön felvételével járó adósság. A kölcsönfelvételhez hasonlóan a műszaki adósságunknak is ára van, kamatot kell majd fizetni: abból a pluszmunkából adódik, ami a későbbi fejlesztések során jelentkezik, és az oka bizony a tűzoltásként létrehozott kód.

Ennek tudatában több lehetőségünk van. Dönthetünk úgy, hogy folyamatosan fizetjük ezt a kamatot, vagy dönthetünk úgy is, hogy refaktoráljuk a kódunkat: a tűzoltást újratervezzük majd implementáljuk. Így tulajdonképpen megfizetjük a minket terhelő adósságot. Természetesen elő is törleszthetünk: csak az adósság egy részét fizetjük ki, ezzel a további kamatterheket csökkentjük. 

A hasonlat azt is segít megérteni, hogy a tűzoltás miért veszélyes bár érthető megoldás. Egy hitelfelvétel segítségével ki lehet használni egy adódó üzleti lehetőséget. Hasonló módon, annak érdekében, hogy teljesítsenek fontos határidőket a fejlesztők is felhalmozhatnak műszaki adósságot. Ezzel kapcsolatban a leggyakoribb probléma az adósságcsabda: a fejlesztők elvesztik az irányítást a műszaki adósságuk felett, így a jövőben fejlesztési kapacitásukat megbénítják a kamatfizetési kötelezettségek.

A furfangos része természetesen a műszaki adósságnak az, hogy a pénzhitellel ellentétben ezt nem lehet hatékonyan mérni. A kamatfizetési kötelezettség persze lehúzza a csapat hatékonyságát. És mivel a hatékonység nem mérhető, így műszaki adósságunk hatása valójában felmérhetetlen.

Könnyű elfelejteni, hogy adósság által pénzt csak úgy termelhetünk, ha bármibe is fektetünk, a végén terméket vagy szolgáltatást készítünk és azt el is adjuk. A legnagyobb költsége a műszaki adósságnak az a tény, hogy lelassít minket, ugyanis gyengíti a jövőben szállítandó fejlesztések előállításához szükséges képességünket. Tehát járulékos költségként fennáll az a lehetőség is, hogy ez még további bevételkiesést eredményez végül. Ha elfogadjuk a tervezés stabilitásának elvét, akkor a tűzoltással az előtt kell elkészülnünk egy-egy szállítandó egységgel, mielőtt elérjük a jól tervezett megoldáshoz szükséges időkeretet, hiszen csak így lesz esélyünk az adósságból előnyt kovácsolni. De a műszaki adósság begyűjtése gyakran olyan mértékben lelassíthatja a fejlesztő csapatot, hogy képtelen lesz időben szállítani.

A műszaki adósság számos különböző forrásból származhat, ezek közül van ami hasznos és van ami nem. Ennek leírására a műszaki adósság négyszögét használom.

(Amennyire meg tudom mondani, Ward ezt az elgondolását először az 1992-es OOPSLA-ra készített élménybeszámolójában mutatta be. Ezen kívül egy ehhez kapcsolódó vitát is folytatott a wiki-jén.)

Az eredeti cikk: Technical Debt

A cikkben hivatkozott érdekesebb cikkeket (a hatékonység nem mérhető, a tervezés stabilitásának elve, a műszaki adósság négyszöge) terveink szerint a jövőben itt a blogon lefordítjuk majd.