Ce este datoria tehnică?

De ce contează

Fiecare scurtătură pe care o iei ca să prinzi un termen împrumută viteză din viitor. Poate fi un schimb inteligent, livrezi acum și înveți acum, dar împrumutul este real. Pe măsură ce datoria se strânge, fiecare funcție nouă durează puțin mai mult, se strică puțin mai des și sperie echipa puțin mai tare. Pentru un fondator, simptomul este un produs care odată se mișca rapid și acum se târăște, fără un motiv evident. Motivul este de obicei o datorie pe care nimeni nu a ales să o plătească înapoi.

Nu este același lucru cu cod prost

O bază de cod dezordonată este pur și simplu neglijentă. Datoria tehnică este un schimb deliberat: știai calea mai curată și ai ales-o intenționat pe cea mai rapidă, ca să livrezi și să înveți mai devreme. Aceasta este o decizie legitimă, mai ales pentru un MVP timpuriu, unde scopul este să testezi o idee, nu să construiești o catedrală. Disciplina este să notezi datoria, să o numești și să programezi curățenia, ca o scurtătură conștientă să nu putrezească în tăcere într-o harababură pe care nimeni nu o mai înțelege.

Greșeala frecventă (în ambele direcții)

Eșecul obișnuit este să nu o plătești niciodată înapoi: continui să te împrumuți până când dobânda, schimbări lente și buguri constante, îți mănâncă întreg bugetul de inginerie. Eșecul opus este supra-ingineria timpurie, să șlefuiești și să pregătești pentru viitor cod pentru un produs care nu a dovedit încă faptul că îl vrea cineva. Ambele irosesc bani, la fel ca a treia cale, cea tăcută: să lași extinderea scopului să îndese funcții grăbite de ultim moment, unul dintre cele mai rapide moduri de a lua datorie pe care nimeni nu a decis să o ia. Soluția este aceeași disciplină în oricare caz: ia datorie intenționat, ține-o evidență și plătește-o prin refactorizare constantă, nu printr-o singură rescriere terifiantă. Când predăm un proiect, runbook-ul și documentația există parțial tocmai ca datoria pe care o duci să fie vizibilă, nu o surpriză pe care o moștenește următoarea echipă.