De ce experiența dezvoltatorilor contează mai mult decât tehnologia

Fiecare an aduce o nouă tehnologie „obligatorie”. Un framework mai rapid, o bază de date mai inteligentă, un limbaj mai la modă. Este tentant să crezi că instrumentul potrivit este ceea ce desparte un produs excelent de unul eșuat. Dar dacă te uiți la datele despre de ce reușesc sau eșuează, de fapt, proiectele software, apare o altă imagine: cea mai mare variabilă nu este aproape niciodată tehnologia. Sunt oamenii care iau deciziile.

Tehnologia se schimbă. Judecata rămâne.

Instrumentele vin și pleacă. Framework-ul lăudat de toată lumea acum cinci ani este adesea exact cel de la care echipele migrează astăzi. Ceea ce nu expiră este judecata inginerească — să știi ce problemă rezolvi prima, unde se ascund riscurile și care „scurtătură inteligentă” va deveni discret urgența de anul viitor.

Un inginer cu experiență și un începător pot primi exact același stack modern și pot livra rezultate complet diferite. Nu pentru că unul a tastat mai repede, ci pentru că experiența schimbă fiecare decizie luată pe parcurs: cum sunt structurate datele, cum sunt tratate erorile, cum se va comporta sistemul sub încărcare reală.

Ce spun datele despre proiectele software

Cifrele aici sunt îngrijorătoare și au rămas constante de zeci de ani.

Cea mai citată cercetare pe termen lung, rapoartele CHAOS ale The Standish Group, a constatat în mod repetat că doar aproximativ o treime dintre proiectele software sunt livrate cu succes, în timp ce majoritatea sunt „cu probleme” (întârziate, peste buget sau cu funcționalități lipsă) ori eșuează complet. Tehnologia mai nouă nu a schimbat prea mult acest tipar — cauzele eșecului țin covârșitor de oameni, planificare și decizii, nu de instrumente.

Un studiu de referință realizat de McKinsey & Company împreună cu Universitatea Oxford, care a analizat 5.400 de proiecte IT mari, a descoperit că, în medie, acestea au depășit bugetul cu 45% și timpul cu 7%, livrând cu 56% mai puțină valoare decât s-a estimat. Proiectele care au rămas pe drumul cel bun nu au fost cele cu cea mai spectaculoasă tehnologie — au fost cele cu o direcție tehnică solidă și echipe cu experiență care au făcut compromisuri disciplinate.

Costul real, măsurabil, al greșelilor

Ingineria slabă nu este doar un risc abstract — are un preț, iar acesta este uriaș.

În 2002, un studiu al National Institute of Standards and Technology (NIST) a estimat că doar testarea software inadecvată costa economia SUA aproximativ 59,5 miliarde de dolari pe an. Două decenii mai târziu, Consortium for Information & Software Quality (CISQ) a estimat costul total al calității slabe a software-ului în SUA la aproximativ 2,08 trilioane de dolari în 2020 — generat în mare parte de proiecte eșuate, probleme moștenite și defecte pe care un review făcut cu experiență le-ar fi prins din timp.

Există un principiu bine stabilit în spatele acestor cifre: cu cât o problemă este descoperită mai târziu, cu atât costă mai mult să o repari. Un defect prins în faza de proiectare este ieftin. Același defect descoperit în producție — după ce îl întâlnesc clienții — poate costa de ordine de mărime mai mult. Experiența este ceea ce mută aceste depistări mai devreme.

De ce doi ingineri pot diferi de 10 ori

Una dintre cele mai vechi și mai frapante descoperiri din cercetarea software este cât de mult variază dezvoltatorii între ei. Studii timpurii asupra productivității programatorilor (Sackman, Erikson și Grant, 1968) au găsit diferențe de peste 10 ori între indivizi care lucrau la aceeași sarcină — un rezultat popularizat mai târziu în clasicul lui Fred Brooks, The Mythical Man-Month.

Esențial este că acea diferență nu ținea de viteza de tastare sau de inteligența brută. Ținea de experiență și de abordare: cei mai buni ingineri alegeau arhitecturi mai bune, evitau fundăturile și scriau cod pe care ceilalți puteau construi. Zeci de ani mai târziu, Peopleware de DeMarco și Lister a ajuns la o concluzie similară — diferențele dintre echipe le eclipsează pe cele dintre instrumente.

Contează capabilitățile, nu stack-ul tehnologic

Poate cea mai puternică dovadă modernă vine de la DORA (DevOps Research and Assessment), programul de cercetare pe mai mulți ani din spatele cărții Accelerate și al rapoartelor anuale State of DevOps ale Google. Studiind mii de organizații, DORA a constatat în mod constant că echipele cu cele mai bune performanțe livrează mult mai frecvent, greșesc mult mai rar și se recuperează după incidente dramatic mai repede decât cele cu performanțe slabe.

Concluzia-cheie: aceste rezultate sunt prezise de capabilități și practici — testare, automatizare, arhitectură, responsabilitate clară — nu de instrumentele sau limbajele pe care o echipă s-a întâmplat să le aleagă. Iar acele capabilități sunt exact ceea ce construiește experiența.

Ce îți oferă, de fapt, experiența

Așadar, ce îți oferă o echipă cu experiență și pe care una mai nouă, folosind aceeași tehnologie, nu poate? În practică, acestea:

• Anticipare. Depistarea problemei înainte să devină scumpă, în loc de reacție după ce deja este.
• Compromisuri mai bune. Să știi când „suficient de bun” este corect și când este o capcană.
• Mai puține fundături. Evitarea arhitecturilor care merg în demo și se prăbușesc în producție.
• Calm în condiții reale. Gestionarea datelor dezordonate, a cazurilor limită și a scalării — părțile pe care utilizatorii chiar le întâlnesc.
• Cost total mai mic. Pentru că greșelile scumpe sunt cele care nu se mai fac niciodată.

Nimic din toate acestea nu apare într-o listă de funcționalități sau într-un logo de tehnologie. Toate se văd în lunile și anii de după lansare.

Concluzie

Tehnologia contează — dar este un instrument, iar instrumentele sunt la fel de bune ca mâinile care le țin. Datele sunt remarcabil de consecvente: proiectele nu reușesc datorită framework-ului și nici nu eșuează din cauza lui. Ele se ridică sau cad în funcție de experiența, judecata și disciplina oamenilor care le construiesc.

La theCoders, alegem tehnologia cu grijă — și apoi lăsăm experiența să facă munca grea. Pentru că, în final, cea mai importantă decizie nu este ce instrument folosești. Este cine decide cum să îl folosească.

Surse

• The Standish Group — CHAOS Report (rate de succes și eșec ale proiectelor software)
• McKinsey & Company și Universitatea Oxford — Delivering large-scale IT projects on time, on budget, and on value (2012)
• National Institute of Standards and Technology (NIST) — The Economic Impacts of Inadequate Infrastructure for Software Testing (2002)
• Consortium for Information & Software Quality (CISQ) — The Cost of Poor Software Quality in the US (2020)
• N. Forsgren, J. Humble, G. Kim — Accelerate și rapoartele DORA / State of DevOps
• Sackman, Erikson & Grant (1968), despre variația productivității programatorilor; discutat în F. Brooks, The Mythical Man-Month
• T. DeMarco & T. Lister — Peopleware: Productive Projects and Teams