Cum aleg tehnologia potrivită fără să fiu inginer

Întrebarea pe care o aud cel mai des sună așa: "Vlad, ce tehnologie ar trebui să folosesc?" Iar răspunsul cinstit, aproape de fiecare dată, e că întrebarea nu are un răspuns până nu schimbăm întrebarea.

"Care e cea mai bună tehnologie" presupune că există un clasament obiectiv, ca la mașini sau la telefoane. Nu există. O tehnologie e bună sau proastă doar în raport cu situația ta: cine o scrie, cine o întreține, cât de repede trebuie să ajungi pe piață, unde trebuie să reziste. Două echipe identice ca produs pot lua decizii corecte complet opuse pentru că lucrează în contexte diferite.

Am trecut prin asta din ambele poziții. Am condus arhitectura ca CTO la o companie de legaltech, unde fiecare decizie de stack ne lega de ani de mentenanță. Am construit cel mai performant model românesc de speech-to-text, integrat într-un produs evaluat la 4 milioane de euro, unde alegerea greșită de infrastructură ar fi costat scump și greu de reparat. Tiparul care se repetă nu e "ce tool e cel mai tare". E "ce constrângeri ai uitat să pui pe masă". Detaliile despre rolurile mele tehnice sunt pe vladtudor.com.

De ce "care e cel mai bun stack?" e întrebarea greșită

Întrebarea pleacă de la tool și caută o justificare. Decizia bună merge invers: pleacă de la situația ta și lasă constrângerile să elimine opțiunile.

Problema cu abordarea "tool-first" e că te face vulnerabil la modă. În fiecare an apare un framework sau o bază de date pe care toată lumea o laudă pe Twitter, iar fondatorii o aleg ca să nu rămână în urmă. Șase luni mai târziu se trezesc că documentația e subțire, că nu găsesc oameni care s-o cunoască și că fiecare problemă banală cere o săptămână de cercetare. Au optimizat pentru cum arată decizia, nu pentru cum se simte peste un an de mentenanță.

Reformularea e simplă: nu "ce e cel mai bun", ci "ce e suficient de bun și pe care îl pot duce cu resursele pe care chiar le am". Aceeași logică de constrângeri-întâi pe care o aplic și când discutăm dacă merită construit ceva de la zero.

Cele patru constrângeri din care decizi

Aproape orice decizie de tehnologie se reduce la patru întrebări. Dacă ai răspuns sincer la ele, alegerea aproape se face singură.

Cine o întreține

Asta e prima și cea mai ignorată. O tehnologie pe care nimeni din echipă n-o cunoaște nu e o alegere, e o datorie. Întreabă-te cine va scrie codul săptămâna asta și cine îl va repara la 2 noaptea peste un an. Dacă răspunsul ești tu singur, alege ce știi deja. Dacă ai o echipă mică, alege ceva pentru care găsești oameni pe piață fără să cauți luni întregi.

Cât de repede trebuie să livrezi

La început, viteza cu care ajungi la primii utilizatori bate aproape orice considerent tehnic. O tehnologie cu care livrezi în trei săptămâni e mai bună decât una "superioară" cu care livrezi în trei luni, pentru că prima îți dă feedback real iar a doua îți dă doar arhitectură frumoasă. Performanța contează când ai utilizatori care o cer, nu înainte.

Unde trebuie să scaleze

Pune întrebarea cinstit: chiar ai nevoie de scară acum, sau presupui că vei avea? Majoritatea produselor nu ajung niciodată la scara pentru care se pregătesc din prima zi. E în regulă să alegi o soluție care merge bine până la primele mii sau zeci de mii de utilizatori și să rezolvi scara când chiar o ai. Scara prematură e o factură pe care o plătești sigur pentru o problemă pe care poate n-o vei avea.

Ce știi deja

Cunoașterea ta existentă e un activ real, nu o scuză. Dacă știi bine un anumit set de tehnologii, faptul că pornești de pe el îți dă viteză și mai puține surprize. Tehnologia nouă are mereu un cost ascuns de învățare pe care îl plătești în exact momentul în care ai cel mai puțin timp: la început.

Monolit sau microservicii

Aceasta e decizia de arhitectură pe care fondatorii o iau cel mai des greșit, și aproape mereu în aceeași direcție: spre microservicii, prea devreme.

Un monolit e o singură aplicație care conține toată logica. Microserviciile sparg aplicația în multe servicii mici care comunică între ele. Microserviciile rezolvă o problemă reală, dar e o problemă de organizare: apare când ai multe echipe care se încurcă una pe alta lucrând în același cod. Dacă ești unul, doi sau cinci oameni, nu ai acea problemă. Ai problema opusă, și anume să livrezi repede cu puțini oameni, iar microserviciile o fac mai grea, nu mai ușoară.

Recomandarea practică: începe cu un monolit bine structurat, cu granițe clare în interior. Când chiar simți durerea pe care o rezolvă microserviciile, vei ști unde să tai, pentru că granițele sunt deja acolo. Inversul (să pornești cu microservicii și să-ți dorești că ai avut un monolit) costă mult mai mult.

Build sau servicii gata făcute (managed services)

A doua decizie repetitivă: construiești o componentă tu, sau plătești un serviciu care ți-o oferă gata făcută? Autentificare, plăți, trimitere de email, căutare, infrastructură de bază de date. Pentru fiecare există ambele variante, iar instinctul fondatorului tehnic e adesea să le construiască, fiindcă poate. "Poate" nu e același lucru cu "ar trebui".

Regula pe care o folosesc: construiește ce te diferențiază, cumpără restul. Dacă autentificarea utilizatorilor nu e motivul pentru care clienții te aleg pe tine, n-are sens să petreci săptămâni construind-o și ani întreținând-o. Plătești un serviciu și îți investești timpul scump în partea care chiar contează. Capcana inversă, să cumperi exact componenta care e inima produsului tău, te lasă fără controlul asupra lucrului de care depinzi cel mai mult.

Cele două greșeli care costă cel mai mult

Aproape toate eșecurile de stack pe care le-am văzut se reduc la două tipare.

Primul: over-engineering pentru o scară pe care n-o ai. Echipe mici care construiesc infrastructură de companie mare, "ca să fie pregătite". Pregătite pentru ce? Cheltuiesc luni pe arhitectură pentru milioane de utilizatori, în timp ce produsul nu are încă o sută. E cea mai scumpă formă de amânare a momentului în care afli dacă produsul tău contează cu adevărat.

Al doilea: rescrierea totală. Apare când o echipă decide că stack-ul actual e o greșeală și trebuie reconstruit de la zero. Rescrierile mari sunt printre cele mai riscante proiecte din software, fiindcă petreci luni reconstruind ce ai deja, fără să adaugi valoare pentru utilizator, în timp ce produsul vechi îți cere în continuare atenție. Joel Spolsky, fondator al Stack Overflow și Trello, a numit decizia de a rescrie codul de la zero "cea mai gravă greșeală strategică pe care o poate face o companie de software" (Joel on Software, "Things You Should Never Do, Part I", 2000). Aproape mereu există o cale incrementală mai puțin riscantă decât rescrierea totală.

Observă că ambele greșeli vin din aceeași sursă: o decizie de tehnologie luată din emoție sau din modă, nu din constrângeri. Una optimizează pentru un viitor imaginar, cealaltă fuge de un prezent care de fapt e reparabil.

Cine ar trebui să decidă într-o echipă

Decizia finală o iei tu, fondatorul sau lead-ul, fiindcă tu duci consecințele. Dar felul în care ajungi la ea contează.

Pune persoana care va întreține codul să apere alegerea, și pune-o s-o apere în fața constrângerilor, nu a preferințelor. "Îmi place mai mult X" nu e un argument. "Pe X livrăm mai repede și avem doi oameni care îl știu" e un argument. Diferența dintre cele două propoziții e exact diferența dintre o decizie de echipă și o ceartă de echipă.

Cel mai dificil caz e când nu ai pe cineva tehnic de încredere intern și miza e mare. Atunci fie singura voce din cameră câștigă pentru că e singura, fie cea mai tare câștigă pentru că e cea mai tare. Niciuna nu e un mod bun de a decide pe ceva ce te leagă ani de zile. Aici o a doua opinie din afară, de la cineva care a luat decizia asta de mai multe ori, te scoate din capcană fără să-ți ia controlul din mâini. Dacă te întrebi cine să fie acel cineva, merită să înțelegi diferența dintre un fractional CTO și un Tech Coach: unul îți conduce ingineria, celălalt te ajută să decizi singur.

Eu nu aleg stack-ul în locul tău. Pun întrebările care scot la suprafață constrângerile pe care nu le-ai formulat, te ajut să separi decizia reversibilă de cea care te leagă, și te las cu o decizie pe care o poți apăra. Tu înțelegi tehnologia, tu iei decizia.