- A débeda técnica son os atallos que se toman hoxe e se pagan despois, con xuros.
- Non aparece en ningún balance: medra en silencio ata que o sistema comeza a renxer.
- Acumúlase por prazos axustados, falta de documentación, cambios de desenvolvedor e exceso de plugins.
- Desde fóra custa vela; a forma máis fiable de detectala a tempo é unha revisión técnica independente.
Hai unha metáfora no desenvolvemento de software que describe con precisión algo que pasa en case todos os proxectos web: a débeda técnica. Acuñouna o programador Ward Cunningham a comezos dos anos 90, e segue a ser a mellor forma de explicarlle este problema a quen non programa.
A idea é simple. Tomas un atallo: unha solución rápida que funciona agora, pero que non é a mellor maneira de resolver o problema. Nese momento contraes unha débeda. Igual ca unha débeda financeira, esa decisión ten un custo diferido. Non o pagas hoxe. Págalo despois, con xuros.
O problema é que a débeda técnica non aparece en ningún balance. Non xera alertas nin ten unha data de vencemento visible. Medra soa, en silencio, ata que o sistema comeza a renxer e ninguén entende por que.
Como se acumula sen que ninguén o decida
A débeda técnica raramente é o resultado dunha decisión consciente de facer as cousas mal. Case sempre se acumula por razóns que no seu momento parecían razoables.
O prazo aperta e hai que entregar. Escóllese a solución que funciona agora, coa intención de mellorala despois. Ese despois nunca chega, porque o seguinte proxecto xa está á espera.
O desenvolvedor que construíu unha parte do sistema xa non está, e non deixou nada escrito. O novo non entende as decisións que se tomaron, así que constrúe enriba sen tocar o que hai. Modificalo implica un risco e un tempo que non están no orzamento.
Instálase un plugin para resolver algo axiña. Funciona. Instálanse 5 máis. Cada un engade a súa propia capa de lóxica, as súas actualizacións e os seus posibles conflitos, e case nunca se revisa un plugin antes de instalalo. O sistema medra en complexidade sen que ninguén o planificase.
Ningunha destas decisións, por separado, é un desastre. O desastre chega cando se acumulan durante meses ou anos sen que ninguén faga limpeza.
As 3 formas en que a débeda técnica destrúe un proxecto
A débeda técnica non destrúe os proxectos dun golpe. Desgástaos. Ao principio é molesta. Co tempo, vólvese bloqueante.
Primeiro, ralentiza o desenvolvemento. Canta máis débeda ten un proxecto, máis tempo leva calquera cambio. O que debería ser unha modificación de 2 horas convértese nunha investigación de 2 días. Ninguén entende de todo como está construído o sistema e cada decisión pode ter consecuencias imprevistas. Os orzamentos disparan, os prazos alónganse e o cliente frústrase sen entender por que algo sinxelo leva tanto tempo.
Despois, multiplica os erros. Nun sistema con moita débeda técnica, as falladas teñen unha característica particular: arranxar unha xera outra. O código está tan entrelazado que é difícil tocar algo sen que repercuta noutra parte. Os erros en produción vólvense máis frecuentes e as actualizacións pasan de ser melloras rutineiras a operacións de risco.
Finalmente, bloquea o crecemento. Chega un punto en que engadir funcionalidades novas sobre unha base con moita débeda técnica é máis caro que refacelo todo desde cero. O proxecto que comezou ben convértese nunha trampa: demasiado custoso de manter, demasiado arriscado de modificar e demasiado enguedellado para pasarllo a outro desenvolvedor sen semanas de análise.
Ese é o momento en que o cliente descobre que o seu investimento de hai 3 anos xa non admite melloras graduais. Hai que comezar de novo. E esa conversa sempre é difícil.
Por que é tan difícil de detectar desde fóra
Se a débeda técnica fose visible, sería doado xestionala. O problema é que, desde fóra, un proxecto con moita débeda pode parecer perfectamente san.
A web funciona. As páxinas cargan. Os formularios envían. O cliente actualiza contidos sen problema. Todo parece en orde.
O que non se ve desde o panel de administración é a calidade do código que sostén todo iso. Se está estruturado para medrar sen friccións ou se é un castelo de naipes que aguanta mentres ninguén o toque. Se os plugins instalados son os mínimos necesarios ou unha acumulación de solucións parciais que interactúan de formas que ninguén controla.
Aínda así, hai sinais que calquera pode notar sen ler unha liña de código:
- Cada cambio pequeno tarda máis e custa máis ca o anterior.
- As actualizacións aprázanse “por se rompen algo”.
- Só unha persoa se atreve a tocar certas partes do sistema.
- Os mesmos erros volven aparecer despois de cada arranxo.
- Ninguén sabe explicar para que serve a metade dos plugins instalados.
Se recoñeces 2 ou 3 destes sinais, é probable que haxa débeda acumulada. Para saber canta e onde, a forma máis fiable é unha revisión técnica feita por alguén con criterio dabondo para avaliar non só se o sistema funciona, senón como está construído e que implica mantelo e facelo medrar.
A diferenza entre débeda técnica inevitable e evitable
Non toda a débeda técnica é igual, e entender a diferenza cambia a forma de xestionala.
Hai débeda técnica inevitable. Todo proxecto toma decisións con información incompleta. O que hoxe parece a mellor solución pode non selo dentro de 2 anos, cando o negocio cambie, aparezan ferramentas novas ou o volume de datos sexa 10 veces maior. Esa débeda é o custo normal de construír software en condicións reais. Xestiónase con revisións periódicas que modernicen o sistema de forma controlada.
E hai débeda técnica evitable. A que se xera por non facer as preguntas correctas ao principio. Por escoller a solución máis rápida sen pensar no custo a longo prazo. Por traballar con provedores que optimizan para entregar rápido e non para o que vén despois, que é xusto o que explica o custo real dunha web barata. Esa débeda non é inevitable. É unha elección, aínda que non sempre consciente.
A diferenza importa porque determina que se pode facer con ela. A débeda inevitable xestiónase. A evitable prevense, e para iso cómpre que alguén no proxecto faga as preguntas difíciles desde o principio.
Que fai diferente a un desenvolvedor que pensa no longo prazo
Un desenvolvedor que traballa pensando no longo prazo toma decisións distintas ás de quen só optimiza para entregar rápido.
Non instala un plugin cando pode escribir 50 liñas de código que resolven exactamente o problema sen engadir dependencias. Non copia unha solución dun titorial sen entender o que implica no contexto concreto do proxecto. E non entrega sen documentar, porque sabe que quen veña despois (ou el mesmo dentro de 6 meses) vai precisar entender que se construíu e por que. Para iso serve documentar as decisións técnicas, non só o código.
Esas decisións levan máis tempo a curto prazo e ás veces son difíciles de xustificar nun orzamento axustado. Pero son exactamente as que determinan se un proxecto segue a ser mantible e escalable dentro de 3 anos ou se se converte nunha bomba de reloxería.
A débeda técnica non é un problema técnico. É un problema de criterio. E o criterio non se compra por horas: recoñécese en como alguén toma decisións cando ninguén o está a mirar.
En Baqueiro construímos pensando na seguinte entrega, non só na data límite de hoxe. Se o teu proxecto ten síntomas de débeda técnica acumulada (desenvolvemento cada vez máis lento, erros frecuentes, orzamentos que se disparan), cóntanos que está a pasar: facemos unha revisión e dicímosche con claridade o que vemos.