Hogyan keletkezik a gyakorlatban?
Határidő szorít, ezért a fejlesztő bedrótozza az áfakulcsot a kódba, ahelyett hogy beállíthatóvá tenné. Működik, mindenki örül. Aztán két év múlva változik az áfa, és ami egy beállítás lenne, az három napi keresgélés tizenhét helyen a kódban. Ez a technikai adósság: a megspórolt egy óra visszajön három napként, kamatostul.
Nem csak hanyagságból keletkezik — sokszor tudatos döntés. Egy MVP-nél teljesen észszerű egyszerűbb megoldást választani, hiszen még azt sem tudjuk, kell-e a funkció egyáltalán. A baj az, ha az adósságról senki sem tud, és sosem kerül visszafizetésre.
Miről ismered fel megrendelőként?
Tipikus tünetek: minden apró módosítás gyanúsan sokáig tart és sokba kerül; egy javítás után két másik dolog romlik el; a fejlesztő fél hozzányúlni bizonyos részekhez. Ha a rendszered ilyen, valószínűleg adósság nyomja — és minden új funkcióval kamatot fizetsz.
Én úgy kezelem, hogy a tudatos rövidítéseket dokumentálom és jelzem feléd: ez most gyorsjavítás, ennyi idő rendesen megcsinálni, akkor éri meg, ha a funkció bevált. Így te döntesz az adósságról — mert végső soron a te pénzed kamatozik.