Deute tècnic: quan (i per què) externalitzar la refactorització és la millor inversió
"Ja ho netejarem més endavant." Les paraules més repetides a totes les startups de software. I les que menys es compleixen.
El deute tècnic s'acumula en silenci. Al principi ni el notes. Una drecera aquí per arribar a temps al deadline, un workaround allà perquè no hi havia temps de fer-ho bé, un test que ningú no va escriure perquè el llançament era l'endemà. Cada decisió, per separat, és raonable. El problema és que es van sumant.
I un dia t'adones que els desplegaments triguen dues hores. Que un enginyer nou triga 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.
Soc enginyer des de finals dels noranta, i n'he passat una bona part dins de codebases enterprise on aquella neteja no va arribar mai. No he vist ni una sola vegada que el deute tècnic es resolgui sol. El dia que en notes els símptomes ja fas tard — però esperar més només ho empitjora.
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ú deixa anotat que aquell deute s'haurà de retornar.
Deute accidental. Codi que s'ha degradat per manca d'experiència, per manca de revisió, o simplement per l'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 saps que hi és. L'accidental sol aflorar quan ja surt car d'arreglar.
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 exigeix entendre capes de complexitat acumulada, navegar entre dependències ocultes i creuar els dits perquè no peti res on menys t'ho esperes.
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 barallar-se amb un codebase hostil. Quan el teu equip passa més temps posant pegats i navegant per codi espagueti que creant valor, la moral cau. I quan la moral cau, la gent marxa. Substituir un enginyer senior et costa mesos de selecció, onboarding i adaptació — més tot el coneixement del sistema que se'n va per la porta amb ell.
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 els costos del deute tècnic són tan clars, per què no el paga l'equip que el va generar? Perquè hi ha forces sistèmiques que hi juguen en contra:
La pressió de producte sempre guanya. A l'sprint planning, "refactoritzar el mòdul d'autenticació" competeix contra "construir la funcionalitat que ens ha demanat el client més gran". Endevina quina guanya sempre. La refactorització es va posposant sprint rere sprint, trimestre rere trimestre.
L'equip no pot fer les dues coses alhora. Refactoritzar codi legacy demana concentració profunda. Construir funcionalitats noves, també. Demanar a un equip que faci les dues coses simultàniament és demanar-li que les faci totes dues malament. El context switching entre "construir de nou" i "arreglar el vell" destrossa la productivitat.
Ceguesa per familiaritat. El teu equip viu dins d'aquell codi cada dia. N'ha normalitzat els problemes. El workaround que van muntar fa un any per esquivar un bug s'ha convertit en "el sistema funciona així". Un patró que un enginyer extern assenyalaria com a antipattern en deu minuts, l'equip intern el veu com "la nostra manera de fer les coses".
Manca de distància emocional. El codi el van escriure ells. Refactoritzar-lo vol dir admetre que es va fer malament. I això incomoda. Un equip extern no arrossega aquesta motxilla — veu codi, no història personal.
A favor d'externalitzar la refactorització
Externalitzar la refactorització no és admetre cap fracàs. És la decisió estratègica més rendible que pots prendre quan el teu equip no té capacitat per abordar-la internament.
Mirada nova. Un equip extern d'enginyers senior arriba sense idees preconcebudes. Detecta els antipatterns que el teu equip ha normalitzat. Identifica les dependències circulars que ningú no havia dibuixat mai en cap diagrama. Troba el codi mort que ningú s'atreveix a esborrar "per si de cas". Aquesta perspectiva de fora és impossible de replicar des de dins.
Dedicació exclusiva. Mentre el teu equip intern continua lliurant funcionalitats — perquè el negoci no s'atura —, l'equip de refactorització treballa exclusivament sobre el deute tècnic. Sense cap sprint planning que l'obligui a triar entre una feature i un refactor. Sense context switching. Concentració total a deixar el codebase millor de com l'han trobat.
Engagement acotat en el temps. No és un compromís indefinit. Són de 4 a 8 setmanes de feina concentrada amb objectius clars i lliurables mesurables. "Al final d'aquest engagement, el pipeline de CI trigarà menys de 10 minuts, la cobertura de tests superarà el 70%, i els tres mòduls més acoblats tindran interfícies netes." Si els objectius es compleixen, l'engagement s'acaba. Si queda més feina, s'allarga amb un abast definit.
Transferència de coneixement. Un equip de refactorització seriós no deixa només codi millor — deixa documentació. ADRs (Architecture Decision Records) que expliquen per què es va prendre cada decisió. Millores al pipeline de CI/CD. Guies d'estil que abans no existien. Quan l'equip extern marxa, l'equip intern hereta un codebase millor I unes pràctiques millors per mantenir-lo així.
L'objecció més forta mereix una resposta directa: un equip extern no coneix el teu domini, i una refactorització cega al context del domini pot trencar coses que importen. Concedit. Per això aquest model només funciona quan els enginyers externs lliuren la feina via pull requests que el teu equip revisa — els teus enginyers mantenen el coneixement del domini dins del circuit, i l'equip extern hi aporta la disciplina estructural. Cap dels dos no substitueix l'altre.
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. Aquest és l'ordre en què jo l'atacaria:
1. Pipeline de CI lent. Si el teu pipeline triga 40 minuts, cada enginyer perd temps esperant, perd context i perd flow. Reduir-lo a 10 minuts multiplica la productivitat de tot l'equip.
2. Tests fràgils o inexistents. Si l'equip no s'atreveix a refactoritzar perquè no hi ha tests que li donin confiança, estàs atrapat en un cercle viciós. Uns tests fiables són la base de qualsevol millora.
3. Dependències embolicades. Si tocar el mòdul A sempre trenca el mòdul B sense cap raó aparent, aquesta dependència oculta és la prioritat. Desfer aquests nusos desbloqueja la capacitat de treballar en paral·lel.
4. Onboarding lent. Si un enginyer nou triga tres setmanes a ser productiu perquè ningú no entén del tot com funciona el sistema, la documentació i la simplificació de l'arquitectura tenen un ROI immediat.
El codi que és lleig però funciona, que té variables amb noms poc afortunats, o que s'aguanta sobre un patró antic però estable — això pot esperar. Prioritza per impacte en la productivitat, no per ofensa estètica.
Els números: la fricció surt més cara que arreglar-la
Fes números. Surten més a favor del que et penses.
Suposem que cadascun dels 6 enginyers del teu equip perd, de mitjana, 5 hores a la setmana barallant-se amb el deute tècnic. Són 30 hores setmanals. A un cost carregat de 60 euros l'hora, són 1.800 euros la 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 — un objectiu conservador —, recuperes la inversió en sis a deu mesos. I els beneficis es van acumulant cada mes a partir d'aquí.
Els números exactes variaran segons el teu cas, però l'estructura del càlcul és sempre la mateixa: temps que perd l'equip actual, multiplicat per la durada, multiplicat pel cost. Fins i tot una millora modesta s'amortitza sola.
Un engagement que deixa el teu codebase millor
A Conectia connectem startups europees amb enginyers senior de LATAM que fan exactament aquesta mena de feina. No són enginyers que venen a llegir codi durant dues setmanes i et lliuren un document de recomanacions. Són enginyers que obren PRs, escriuen tests, refactoritzen mòduls, milloren pipelines i documenten decisions.
El model és un engagement acotat en el temps: objectius clars, durada definida, resultats mesurables. El teu equip intern continua lliurant producte. L'equip de refactorització es concentra en el deute. Al final de l'engagement, el teu equip hereta un codebase 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 es resol sol. I cada sprint que passa sense abordar-lo, els interessos es componen.
El deute tècnic està frenant el teu equip? Parla amb un CTO — planifiquem engagements de refactorització acotats en el temps amb enginyers senior que deixen el teu codebase millor de com l'han trobat.
