Pri riešení biznisových problémov alebo príležitostí pomocou softvéru sa veľa dôrazu venuje funkcionalitám (features) a prípadnému následnému odstraňovaniu nedostatkov (defect, bug). Je to pochopiteľné, sú to pre ľudí mimo IT dve jasne uchopiteľné kategórie.

Ak dlhodobo sústredím všetku kapacitu výhradne na vývoj funkcionalít, tak sa mi ľahko môže stať, že sa dostanem do začarovaného kruhu, začne ma prenasledovať stále väčší počet chýb.  Skúsenému CIO sa zježia chlpy ak zistí, že sa v rámci vývoja priebežne neadresuje technologický dlh, alebo sa neodstraňujú potencionálne riziká (security, data protection). Tento krát sa nechcem sústrediť na situáciu, keď ma prekvapí záškodník, a budem čeliť bezpečnostném incidentu.

Ak sa stakeholderi prichytia pri tom, že považujú investície do odstraňovania technologického dlhu softvérových riešení ako neplánované náklady, bude vhodné si teraz naliať čistého vína.

Entropia

Väčšina softvérových riešení (systémov) podlieha zmenám. A ak sa tie zmeny nedejú v nich, tak sa dejú vedľa nich (v iných systémoch s ktorými komunikujú - horizontála, alebo na ktorých základoch stoja - vertikála). Tým, že do systémov realizujeme úpravy, systémy sa zozložiťujú (stávajú sa viac komplexnými).

Modifikáciou systému sa zvyšuje úroveň entropie (neporiadku), kým vedome nezasiahnem proti jeho tvorbe. Pomenovanie pre tento nahromadený a neuprataný neporiadok sa nazýva technologický dlh.

Proces odstraňovania entropie (v softvérovom systéme) sa nazýva refaktoring.

Ak pri navrhovaní softvérového riešenia rešpektujem odporúčania (slabé väzby medzi systémami, návrhové vzory) je menšia pravdepodobnosť, že celá moja chlpatá guľa (enterprise architektúra) bude trpieť príliš skoro na technologický dlh. Ale, príde okamih, a bude.

Čas

Chceme to hneď. ASAP. Prečo softvéristi navrhujú systémy, ktoré podliehajú entropii?!

Základnym dôvodom je čas. Treba hľadať rozumný kompromis medzi tým ako dlho uvažuješ (čas), kým sa do niečoho pustíš. Pomalosť má svoju cenu - Cost of delay. Ako dlho trvá kým sa od nápadu dopracuješ k realizácii?

Na jednej strane Ťa môže postihnúť paralýza analýzy, na opačnej strane zase strmhlavé hodenie sa do riešenia problému bez akéhokoľvek uvažovania v širších súvislostiach (architektúra riešenia, reflektovanie aktuálnych best practices a možností riešenia).

Vo všeobecnosti v neistom prostredí platí, že je lepšie hypotézu overiť v praxi, ako dlho teoreticky laborovať. Ideálne je overovať svoje hypotézy, v čo najmenších krokoch.

Je potrebné hľadať vyvážený pomer medzi tým, ako veľmi pripravujem riešenie na možnú budúcnosť, a ako rýchlo sa mi darí adresovať súčasný problém/požiadavku. Napríklad sa často softvérové riešenie hneď od začiatku komplikuje s očakávaním pre potrebu vysokého škálovania, ktorá nikdy nenastane.

(Kreatívnych) spôsobov ako riešiť ten istý problém pomocou softvérových riešení, je vždy viac ako jeden. IMHO, toto je dôvod - možnosť hračíčkovania - ktorý láka ľudí venovať sa softvérovému inžinierstvu (nerob to pre peniaze).

Refaktoring nie je náklad

Aby to nevyznelo ako čierny scenár, že sa je lepšie vecí nechytať, máme nástroje a techniky, ktoré pomáhajú s tým, aby zmeny aplikované do systému boli čo najmenšie (user story splitting), a transakčné náklady spojené s aplikáciou zmien minimálne (continuous deployment, canary release, feature flag, automated testing).  

Nepozerajme na elimináciu technologického dlhu len ako na náklad, pozerajme na neho ako príležitosť urobiť našu enterprise architektúru viac agilnou. Rovnako sa pýtajme našich dodávateľov, alebo zhotoviteľov softvéru, ako napĺňajú očakávania v tejto “neviditeľnej” rovine, prípadne či sa nám neboja povedať správy, že by sme sa mali refaktoringu tej ktorej aplikácie povenovať.