Innovation debt

Dacă tu, cititorule, faci parte din categoria majoritară a celor care vizitează blogul meu, atunci cu siguranță te-ai confruntat la un moment dat (dacă nu chiar ongoing) cu ”technical debt”. Dacă nu faci parte din categoria majoritară. trebuie să precizez atunci că acest termen înseamnă folosirea într-o aplicație software a unui cod sursă vechi, cu probleme de arhitectură, fără documentație, netestabil automat și multe altele care îl fac greu și scump de întreținut. Chiar dacă pe termen scurt poate fi mai ieftin de menținut o asemenea aplicație, pe termen lung e un pariu pierzător. Dar cam atât vreau să scriu momentan despre technical debt.

Spre deosebire de technical debt, ”innovation debt” atinge mai mult partea umană decât partea tehnică. Își face văzută fața atunci când companiile nu investesc în pregătirea oamenilor și asta pentru că echipele sunt prea preocupate cu finalizarea rapidă a produselor software, cu repararea rapidă și urgentă a ultimelor showstoppere. Presiunea pe divizia de R&D de a finaliza cât mai urgent softul (sau lipsa finanțării) face a aceasta să nu mai fie la curent cu noile limbaje, tehnologii, librării și metodologii. Precum TD-ul poate transforma o minunăție de cod sursă într-un ”big ball of mud”, innovation debt transformă din R(easearch)&D(evelopment) în S(earch)&D(ebug) care tot un fel de BBOM este.

Buun, dar totuși de ce pe termen lung costul asociat este mult mai mare? Sunt mai multe motive:

Cei mai valoroși oameni sunt tentați să plece către plaiuri mai verzi – e simplu, dacă tot timpul cât ești în firmă ești bombardat doar cu taskuri iar timp de training nu este alocat atunci, nu vei învăța nimic nou. Cei mai buni oameni vor vedea asta și își vor pune semne de întrebare, dacă nu cumva peste gard gazonul e mai bun de picnic (și nu fi răutăcios, nu mă refer la păscut).

Costul recrutării va crește – atât în bani cât și în timp efectiv. Vorba umblă printre oameni iar reclama negativă nu este totuși reclamă pozitivă (there’s no such thing as bad publicity – eeh, în cazul ăsta este).

Productivitatea nu crește – tehnologiile noi au fost create tocmai pentru a crește productivitatea. Dacă acestea nu sunt adoptate, ritmul de dezvoltare rămâne același sau dacă nu, chiar scade din cauza codul legacy care trebuie întreținut.

Produsul software va fi greu de întreținut – tot ceea ce ține de IT se schimbă cu rapiditate și asta pentru că așteptările utilizatorilor finali cresc de la an la an (chiar mai repede).  Cu cât codul sursă devine din ce în ce mai mult și nu ține pasul cu evoluția tehnologiei, integrarea unor noi tehnologii devine din ce în ce mai grea. De exemplu, o cerință de bun simț în 2014 este ca site-ul să fie responsiv – fă tu asta unui site a cărui HTML se bazeză pe td, tr, td, tr.

Din păcate chestia asta nu apare brusc, panta de descreștere este lină și în decurs de câțiva ani se poate ajunge jos tare. Citeam pe un blog un exemplu real de care se izbise tipul respectiv: firma la care lucra a primit un nou proiect pentru care oamenii au trebuit să învețe o serie de noi tehnologii și framework-uri, un nou sistem de versionare, testare automată, continous integration, build machine și altele. Oricare dintre cele enumerate ar fi fost ușor de absorbit dar nu toate deodată; proiectul a durat mult mai mult și chiar erau destul de aproape de faliment.

Ok, cred că e cel mai lung articol de până acum și nu vreau să devin pisălog așa că am să mă opresc aici; de asemenea nu vreau să te apuci de căscat citind articolele mele. Într-un următor articol voi scrie despre cum se pot evita costurile descrise mai sus.

Nu fi egoist, dă mai departe să ajungă la tot poporul