517 milliárd dollár. Ritkán látunk ekkora összeget, ezért leírom számjegyekkel is: $517 000 000 000. Az ott 9 darab 0-ás. Ekkora volt a CISQ (Consortium for IT Software Quality) szerint¹ a technikai adóssága az USA-nak, 2018-ban.

A fentiek alapján nyugodtan megállapíthatjuk, hogy a technikai adósság drága mulatság. Ugyanakkor fontos is, a technológiai ipar nagyon sokat foglalkozik a témával. Sőt, már mi is érintettük párszor a blogunkon (pl. itt vagy itt). Ennek ellenére az iparágon kívül kevesen tudják mi is az a technikai adósság. Ez a cikk nekik szól.

Mi az a technikai adósság?

Valaki adósának lenni nem jó érzés. Minél inkább eladósodunk, annál nagyobb rajtunk a nyomás. Ha beszéltél már valakivel, akinek sikerült törlesztenie az adósságát, akkor nagy valószínűséggel felszabadító érzésként élte ezt meg.

A technikai adósság nagyon hasonlít ebben a pénzügyi adósságra. Ugyanúgy mint a pénzügyi adósság esetében, a technikai adósság esetében is kamatot kell fizetnünk. Ez a kamat több formát is felvehet: magas karbantartási, support vagy jogi költségek, régi rendszerek lecserélésének költsége vagy a motiválatlan munkaerő.

Ha nem fizetjük vissza az adósságunkat mielőtt újabb fejlesztéseket végeznénk, folyamatosan akadályokba fogunk ütközni és újabb "kölcsönöket" kell majd felvegyünk. Minél több az adósságot halmozunk fel, annál lassabban tudunk majd előre haladni, míg végül teljesen meg nem fojtja a fejlesztési törekvéseinket.

Ezt a jelenséget nevezzük szoftver entrópiának. A termodinamika második törvénye azt mondja, hogy egy zárt rendszer rendezetlensége nem csökkenhet, csak szintben maradhat vagy növekedhet. Ennek a rendezetlenségnek a mértéke az entrópia. Ivar Jacobson² szerint egy szoftveres rendszer is hasonlóan viselkedik: ha folyamatos karbantartás és beavatkozás nélkül módosítunk egy szoftvert, annak növekedni fog a rendezetlensége, vagyis an entrópiája.

Egy jó példa lehet erre egy ERP rendszer. Egy ilyen rendszer a folyamatosan változó üzleti igények miatt folyamatosan módosul. Ha nincs a dokumentáció frissítve, nincs a forráskód karbantartva vagy nincsenek elvégezve a kötelező technológiai frissítések, akkor bekerülünk abba az ördögi körbe, hogy a rendszert továbbfejleszteni sem lehet már, mert akkora költséggel járna. Ilyenkor nem marad más opciónk mint a "kukázni és cserélni" módszerhez folyamodni.

A technikai adósság egy előremutató mérőszám, amely segítségével számszerűsíthető azoknak a döntéseknek a hatása, amikor egy gyorsabb vagy olcsóbb megoldást választottuk egy rendszer bevezetésénél vagy karbantartásánál.

Képzeljük el a meglévő IT rendszereinket… most pedig képzeljük el, hogy néznének ki azok a rendszerek, ha most kezdenénk el 0-ról felépíteni egy ideális rendszert. Mennyibe kerülne nekünk a meglévő rendszereinket úgy átalakítani, hogy az ideális rendszerhez jussunk? Ez a költség a technikai adósság.

Mi vezet a technikai adósság felhalmozásához?

A technikai adósság felhalmozásához általában egy kompromisszumos döntés meghozatala vezet. Ez a kompromisszum fakadhat időhiány vagy költségcsökkentés miatt.

Ilyen döntés lehet például:

• Szoftverfrissítések elhalasztása;
• Hardver élettartamának túlnyújtása;
• Nem megfelelő szoftvertervezés – amikor a szoftver nem elég rugalmas ahhoz, hogy a változó üzleti igényeknek teret adjon;
• Kód refaktorálásának késleltetése – ahogy az üzleti igények változnak, a forráskód egyes részei nehezen karbantarthatóak és kevéssé hatékonyak lesznek, ezért refaktorálásra lesz szükség. Minél többet halasztjuk a refaktorálást, annál nagyobb lesz a kódbázis és a technikai adósság;
• Dokumentáció frissítésének elmaradása – ahogy változik a kódbázis és a funkcionalitás, a fejlesztői, illetve felhasználói dokumentáció azonnali frissítésére lesz szükség. Ha ez nem történik meg, értékes időt veszítünk amikor újbóli változásokat kell majd eszközölnünk, esetleg kerülő vagy "ragtapasz" megoldások születnek.

A technikai adósság elkerülhetetlen. A szoftver és hardver is rohamtempóban fejlődik, naponta új funkcionális és biztonsági frissítések jelennek meg, ezért már csak pusztán az idő elteltével nő a technikai adósságunk.

A technikai adósság költsége

A technikai adósság eredendően része a szoftvereknek. Az adósság csökkentése viszont nem igazán számszerűsíthető, ezért az IT-nak nehéz feladata van, amikor be kell mutassa a vezetőségnek, hogy miért szükséges mégis erre erőforrásokat fordítani.

A legkönnyebb talán az, ha megnézzük milyen feladatok tartoznak egy szoftver karbantartásához és üzemeltetéséhez. Herb Krasner, a CISQ jelentés szerzője 4 típusú karbantartást különböztet meg.

Korrektív karbantartás

Egy új szoftver verzió élesítése utáni hibák elhárítása. A technikai adósság nagyban hozzájárul a korrektív karbantartás szükségességéhez: minél nagyobb az adósságunk, annál nehezebben átlátható és karbantartható a kód, ami újabb hibákhoz vezet.

A karbantartási költségeknek körülbelül 20%-át képezik a korrektív karbantartási feladatok.

Adaptív karbantartás

Az adaptív karbantartás a változó igények miatt szükséges módosításokhoz kapcsolódik. Hasonlóan a korrektív karbantartáshoz, a technikai adósság jelentősen befolyásolja mennyire könnyű az adaptív módosításokat végrehajtani.

Az adaptív karbantartás teszi ki a karbantartási költségek mintegy 50%-át.

Perfektív karbantartás

A hibák elhárításán és a változó igények miatti módosításokon kívül, sok erőforrást igényel egy szoftver tökéletesítése, a használhatóság és teljesítmény javítása. A technikai adósság, korrektív és az adaptív karbantartáshoz hasonlóan befolyásolja azt, hogy mennyire könnyű ezeket a továbbfejlesztéseket megejteni.

A perfektív karbantartás költségei 25%-át képezik a karbantartási összeköltségnek.

Preventív karbantartás

Preventív karbantartásnak nevezzük az alvó hibák felderítését és javítását, még mielőtt ezek effektív hibákká válnának. Ilyen feladat például a szoftverfrissítés, a biztonsági frissítés vagy a refaktorálás is, de ide sorolhatjuk akár a dokumentáció naprakészen tartását is.

A preventív karbantartás csupán 5%-át teszi ki a teljes karbantartási költségnek, de ha elhanyagoljuk, akkor jelentősen megnövelheti a korrektív, az adaptív és a perfektív karbantartások idejét és költségét. Ez látható az alábbi grafikonon.

A fenti direkt költségnövekedésen a technikai adósságnak egyéb, közvetett hatásai is vannak, mint például:

• A hosszabb fejlesztési ciklusok miatt a felhasználók többet kell várjanak egy új funkcióra vagy módosításra, ezért csökken az ügyfélelégedettség;
• Nehezebb megfelelő fejlesztőket találni a projekthez, magasabbak a betanítási költségek;
• Csökken az IT rendszerek biztonsága, ki leszünk szolgáltatva a támadásoknak.

Hogyan minimalizáljuk a technikai adósságot?

Azt már megállapítottuk, hogy a technikai adósságtól nem lehet teljesen megszabadulni. Ellenben van pár olyan módszer amit a fejlesztő csapatok alkalmazhatnak, hogy jobb legyen a kód minősége és ezáltal redukálják a technikai adósság növekedési ritmusát:

• Minden szoftver, keretrendszer és dokumentáció legyen folyamatosan frissítve;
• Automata tesztelés – az automata tesztek segítenek a fejlesztőknek abban, hogy nyugodtabban hozzányúljanak a kódhoz, legyen szó egy egyszerű módosításról, továbbfejlesztésről vagy refaktorálásról. Automata tesztek nélkül ezek a változtatások nagy kockázattal járnak, ami megnövekedett fejlesztési időhöz és költségekhez vezet;
• Code review – a code review az a folyamat, amikor a fejlesztők egymás kódját ellenőrzik, mielőtt az kikerül egy éles környezetbe. Egy friss pár szem hamarabb észreveszi azokat a hibákat, amik később gondot jelenthetnek;
• Gyökér-ok elemzés – ha valamilyen hibával vagy nem az elvárásoknak megfelelő működéssel találkozunk, szakítsunk időt a gyökér-ok megkeresésére, elemezzük és dokumentáljuk, majd változtassunk a folyamatainkon annak érdekében, hogy ugyanaz a probléma ne fordulhasson ismét elő.

Ha már felgyűlt az adósságunk, akkor fontos kérdés az, hogy miként menedzseljük. A technikai adósság menedzselésére is van módszer:

• Dokumentáljuk a technikai adósságot – minden szükséges javítást, frissítést vagy refaktorálást részletesen dokumentáljunk. Ez az első lépés annak érdekében, hogy tényleg sor kerüljön arra, hogy foglalkozzunk vele, így mindenki tudatában van az adósság mértékével és a vezetőség is nagyobb valószínűséggel fordít majd erőforrásokat a problémák kezelésére;
• Refaktorálás – ha már felhalmozódott valamennyi technikai adósság, akkor azt csak refaktorálás által tudjuk csökkenteni. Refaktorálás esetén célszerű a nagyobb értékű adósságot priorizálni: azok a kódrészletek amik gyakran változnak, előnyt kell élvezzenek azokkal szemben amikhez egyáltalán vagy csak ritkán nyúlunk. Nem érdemes viszont addig várni, amíg annyi nagy értékű adósság összegyűl, hogy utána hetekig csak a refaktorálással foglalkozzunk. Inkább határozzuk meg, hogy a karbantartási és fejlesztési munkákra szánt idő hány százalékát különítjük el refaktorálásra (a technikai adósság mértékétől és komplexitásától függően 5%-33%-ot ajánlott elkülöníteni).

Vannak olyan (ritka) esetek is amikor nem érdemes a technikai adóssággal. Ilyen lehet például, hogy egy termék kivezetés alatt áll, vagy ha a termék csak egy prototípus vagy MVP aminek a célja csupán egy ötlet vagy célpiac validálása.

Következtetések

A technikai adósság elkerülhetetlen, minden IT projekt kötelező velejárója. Nem tudomást venni róla, vagy folyamatosan halasztgatni a közbeavatkozást előbb vagy utóbb megbénítja a rendszert és egyúttal a vállalkozást is.

Éppen ezért a jó fejlesztő csapatok nem halmozzák fel a technikai adósságot, hanem időben menedzselik ezt. A szoftvereket és dokumentációt folyamatosan frissítik, biztosítják a kód minőségét automata tesztek és code review-k segítségével és a továbbfejlesztések mellett folyamatosan időt szakítanak a kódbázis refaktorálására is.