Deute Tècnic: Quan (i Per Què) Externalitzar la Refactorització és la Millor Inversió
"Ja ho netegem després." Les paraules més repetides a tota startup de software. I les que menys vegades es compleixen.
El deute tècnic s'acumula en silenci. Al principi ni el notes. Una drecera aquí per arribar al deadline, un workaround allà perquè no hi havia temps de fer-ho bé, un test que ningú va escriure perquè el llançament era demà. Cada decisió per separat és raonable. El problema és que se sumen.
I un dia t'adones que els desplegaments tarden dues hores. Que un enginyer nou tarda tres setmanes a fer el seu primer commit productiu. Que cada funcionalitat nova introdueix dos bugs. Que els teus millors enginyers comencen a mirar ofertes a LinkedIn perquè estan farts de lluitar contra el codi en comptes de construir producte.
Aquell dia ja has arribat tard per actuar. Però més tard serà pitjor.
Què és realment el deute tècnic (i què no és)
Ward Cunningham va encunyar el terme com una metàfora financera, i és perfecta. El deute tècnic funciona exactament com el deute financer: agafes un préstec (drecera tècnica) per aconseguir alguna cosa avui (lliurar més ràpid), i pagues interessos (complexitat acumulada) fins que retornes el principal (refactoritzes).
Hi ha dos tipus fonamentals:
Deute deliberat. Dreceres preses conscientment per guanyar velocitat. "Sabem que aquest mòdul de pagaments hauria de tenir la seva pròpia capa d'abstracció, però ara mateix l'acoblem directe per arribar al llançament." Això és legítim. Tothom ho fa. El problema és quan ningú anota que cal tornar a pagar-lo.
Deute accidental. Codi que s'ha degradat per falta d'experiència, per falta de revisió, o simplement per entropia natural del software. Ningú va decidir conscientment crear un god object de 3.000 línies — va anar creixent sprint rere sprint sense que ningú s'aturés a refactoritzar.
Tots dos tipus acumulen interessos. La diferència és que el deute deliberat almenys el coneixes. L'accidental sol descobrir-se quan ja és car de pagar.
El cost real d'ignorar-lo
El deute tècnic no és un problema estètic. És un problema de negoci amb costos mesurables:
Velocitat de lliurament en caiguda lliure. El que al mes 3 del producte tardava dos dies, al mes 18 en tarda dues setmanes. No perquè l'equip sigui pitjor, sinó perquè cada canvi requereix entendre capes de complexitat acumulada, navegar dependències ocultes i resar perquè no es trenqui alguna cosa inesperada.
Bugs compostos. En un codebase net, un bug és un bug. En un codebase amb deute tècnic, un bug és un símptoma d'un problema estructural que produeix més bugs. N'arregles un i n'apareixen tres perquè la causa arrel està en un disseny que ningú s'atreveix a tocar.
Frustració de l'equip. Els bons enginyers volen construir coses, no lluitar contra un codebase hostil. Quan el teu equip passa més temps parcheant i navegant codi espagueti que creant valor, la moral cau. I quan la moral cau, la gent marxa. La rotació en equips amb alt deute tècnic és significativament més alta, i reemplaçar un enginyer senior costa entre 6 i 9 mesos del seu salari.
Dificultat per contractar. Els bons enginyers fan preguntes sobre el codebase a les entrevistes. Si la resposta honesta és "és un desastre però hi estem treballant" i no hi ha un pla real, els millors candidats trien una altra oferta.
Risc de seguretat. Dependències sense actualitzar, configuracions legacy, codi que ningú entén del tot — el deute tècnic és també deute de seguretat. I aquest deute es cobra amb incidents.
Per què el teu equip intern no pot resoldre això sol
Si el deute tècnic té costos tan clars, per què no el paga l'equip que el va generar? Perquè hi ha forces sistèmiques que ho impedeixen:
La pressió de producte sempre guanya. Al sprint planning, "refactoritzar el mòdul d'autenticació" competeix contra "implementar la funcionalitat que ha demanat el client més gran". Endevina quin guanya sempre. La refactorització es posposa sprint rere sprint, trimestre rere trimestre.
L'equip no pot fer les dues coses. Refactoritzar codi legacy requereix concentració profunda. Construir funcionalitats noves també. Demanar a un equip que faci les dues coses simultàniament és demanar-li que faci les dues malament. El context switching entre "construir nou" i "arreglar vell" destrueix la productivitat.
Ceguesa de familiaritat. El teu equip viu dins d'aquest codi cada dia. Han normalitzat els seus problemes. El workaround que van fer fa un any per evitar un bug es va convertir en "així funciona el sistema". Un patró que un enginyer extern identificaria com a antipattern en deu minuts, l'equip intern el veu com "la manera com fem les coses".
Falta de distància emocional. El codi el van escriure ells. Refactoritzar-lo implica admetre que es va fer malament. Això és incòmode. Un equip extern no té aquest bagatge — veu codi, no història personal.
El cas per externalitzar la refactorització
Externalitzar la refactorització no és admetre fracàs. És la decisió estratègica més rendible que pots prendre quan el teu equip no té la capacitat d'abordar-la internament.
Ulls frescos. Un equip extern d'enginyers senior arriba sense preconcepcions. Veu els antipatterns que el teu equip ha normalitzat. Identifica les dependències circulars que ningú va dibuixar en un diagrama. Troba el codi mort que ningú s'atreveix a esborrar "per si de cas". Aquesta perspectiva externa és impossible de replicar internament.
Focus dedicat. Mentre el teu equip intern segueix lliurant funcionalitats — perquè el negoci no para —, l'equip de refactorització treballa exclusivament en el deute tècnic. Sense sprint planning que els obligui a triar entre feature i refactor. Sense context switching. Focus pur en deixar el codebase millor del que el van trobar.
Engagement acotat en el temps. No és un compromís indefinit. Són 4 a 8 setmanes de treball enfocat amb objectius clars i lliurables mesurables. "Al final d'aquest engagement, el pipeline de CI tarda menys de 10 minuts, la cobertura de tests està per sobre del 70%, i els tres mòduls més acoblats tenen interfícies clares." Si els objectius es compleixen, l'engagement acaba. Si hi ha més feina, s'estén amb abast definit.
Transferència de coneixement. Un equip de refactorització seriós no només deixa codi millor — deixa documentació. ADRs (Architecture Decision Records) explicant per què es va prendre cada decisió. Millores al pipeline de CI/CD. Guies d'estil que no existien. Quan l'equip extern marxa, l'equip intern hereta un codebase millor I millors pràctiques per mantenir-lo així.
Què prioritzar: el que bloqueja, no el que ofèn
No tot el deute tècnic mereix atenció immediata. El codi lleig però funcional pot esperar. El que no pot esperar és el que bloqueja el teu equip:
Pipeline de CI lent. Si el teu pipeline tarda 40 minuts, cada enginyer perd temps esperant, perd context i perd flux. Reduir-lo a 10 minuts multiplica la productivitat de tot l'equip.
Tests fràgils o inexistents. Si l'equip no s'atreveix a refactoritzar perquè no hi ha tests que els donin confiança, estàs en un cercle viciós. Tests fiables són la base de qualsevol millora.
Dependències embolicades. Si canviar el mòdul A sempre trenca el mòdul B sense raó aparent, aquesta dependència oculta és la prioritat. Separar aquestes dependències desbloqueja la capacitat de treballar en paral·lel.
Onboarding lent. Si un enginyer nou tarda tres setmanes a ser productiu perquè ningú entén com funciona el sistema, la documentació i la simplificació de l'arquitectura tenen ROI immediat.
Codi que és lleig però funciona, que té noms de variables poc descriptius, que fa servir un patró antic però estable — això pot esperar. Prioritza per impacte en productivitat, no per ofensa estètica.
El càlcul de ROI
Fes els números. Són més favorables del que penses.
Suposem que el teu equip de 6 enginyers perd, de mitjana, 5 hores per setmana cadascun lluitant contra deute tècnic. Són 30 hores setmanals. A un cost carregat de 60 euros l'hora, són 1.800 euros per setmana. 7.200 euros al mes. 86.400 euros l'any. Perduts en fricció.
Un engagement de refactorització de 6 setmanes amb dos enginyers senior dedicats pot costar entre 25.000 i 40.000 euros. Si aquest engagement redueix la fricció a la meitat — que és un objectiu conservador —, recuperes la inversió en menys de sis mesos. I els beneficis s'acumulen cada mes després d'això.
Els números reals variaran segons el teu cas, però l'estructura del càlcul és sempre la mateixa: temps perdut per l'equip actual multiplicat per durada multiplicat per cost. Fins i tot millores modestes es paguen soles.
Un engagement que deixa el teu codebase millor
A Conectia, connectem startups europees amb enginyers senior de LATAM que fan exactament aquest tipus de feina. No són enginyers que arriben a llegir codi durant dues setmanes i lliuren un document de recomanacions. Són enginyers que obren PRs, escriuen tests, refactoritzen mòduls, milloren pipelines i documenten decisions.
El model és engagement acotat: objectius clars, durada definida, resultats mesurables. El teu equip intern segueix lliurant producte. L'equip de refactorització s'enfoca en el deute. Al final de l'engagement, el teu equip hereta un codebase que és objectivament millor — més ràpid de desplegar, més fàcil d'entendre, més segur de modificar.
Perquè el deute tècnic no desapareix sol. I cada sprint que passa sense abordar-lo, els interessos s'acumulen.
El teu deute tècnic està frenant l'equip? Parla amb un CTO — planifiquem engagements de refactorització acotats amb enginyers senior que deixen el teu codebase millor del que el van trobar.
