La Deuda Técnica Que Ignoro Conscientemente (y por qué duermo tranquilo)
No toda la deuda técnica es un monstruo bajo la cama; alguna es una herramienta estratégica. Te explico qué tipo de deuda acepto conscientemente para moverme más rápido y cómo la gestiono para que no me explote en la cara.
Hablemos claro sobre la deuda técnica
En el mundo del desarrollo, la "deuda técnica" es el villano universal. Se nos enseña a temerla, a evitarla a toda costa. Es el resultado de atajos, de malas decisiones, de la prisa. Y sí, mucho de eso es cierto. La deuda técnica descontrolada puede hundir un producto, frustrar a un equipo y quemar más dinero que una mala campaña de marketing.
Pero después de años construyendo y lanzando productos, he aprendido algo que no te cuentan en los libros: no toda la deuda técnica es igual. Y más importante aún, hay un tipo de deuda que no solo acepto, sino que genero conscientemente. Y duermo perfectamente por las noches.
La clave está en tratar la deuda técnica como tratas la deuda financiera. Nadie en su sano juicio te diría que te endeudes hasta las cejas con tarjetas de crédito al 25% de interés para comprar lujos. Eso es deuda mala. Pero ¿y una hipoteca a un interés razonable para comprar una casa que aumenta de valor? Eso es deuda buena, una palanca para crecer.
Con la deuda técnica pasa lo mismo.
La deuda que SÍ me quita el sueño
Primero, seamos claros sobre la deuda que NUNCA es aceptable. Esta es la deuda "mala", la que te muerde sin piedad:
* Vulnerabilidades de seguridad: Innegociable. Esto no es un atajo, es una negligencia. * Corrupción de datos: Cualquier cosa que ponga en riesgo la integridad de los datos de los usuarios es veneno puro. * Errores en el 'happy path': Si el flujo principal por el que paga un cliente es inestable, tu negocio es inestable. * Código 'espagueti' en el core: Cuando el corazón de tu aplicación es un nudo imposible de entender, cada cambio es un riesgo existencial.
Esta deuda la ataco con furia. No se negocia, no se pospone. Es el equivalente a tener un agujero en el casco del barco.
La deuda que acepto (y a veces, provoco)
Ahora, vamos a lo interesante. Esta es la deuda "buena" o, mejor dicho, la deuda *estratégica*. Es deuda que asumo con los ojos abiertos para conseguir un objetivo mayor: velocidad y aprendizaje.
Aquí tienes los tipos de deuda que acepto sin remordimientos:
1. Deuda en features experimentales
¿Vamos a probar una nueva funcionalidad para ver si los usuarios la quieren? No voy a construirla sobre una arquitectura de microservicios escalable para 10 millones de usuarios. La voy a construir rápido y funcional. Tal vez el código no sea el más elegante, tal vez repita lógica que ya existe en otro lado. No importa.
El objetivo es validar una hipótesis. Si la funcionalidad es un fracaso (y muchas lo son), borro el código y la deuda desaparece con él. Si es un éxito, ¡genial! Ahora tengo la justificación para invertir tiempo en pagarla, refactorizarla y construirla como se debe.
2. Deuda de 'sobre-ingeniería' evitada
La frase "YAGNI" (You Ain't Gonna Need It) es mi mantra. ¿Necesitamos un sistema de caché distribuida complejísimo cuando tenemos 100 usuarios? No. ¿Necesitamos un pipeline de CI/CD con 15 pasos de validación para un proyecto que actualizamos una vez al mes? Probablemente no.
Prefiero un sistema simple que funciona ahora, aunque sepa que no escalará para siempre. Eso es deuda. Es la deuda de "sé que en el futuro tendré que cambiar esto". Pero la pagaré cuando llegue ese futuro, no antes. Premature optimization es el enemigo de la acción.
3. Deuda de UI/UX no crítica
Soy un fanático de las buenas interfaces. Pero hay una diferencia entre una interfaz funcional y una interfaz perfecta al píxel. A menudo, lanzo interfaces que son "suficientemente buenas". Tal vez esa animación no es 100% fluida, o ese espaciado está 2px desviado.
Lo anoto. Es deuda. Pero si el usuario puede completar su tarea sin fricción, esa deuda puede esperar. Es más importante tener la funcionalidad en producción que pasar una semana puliendo detalles que el 99% de los usuarios no notará.
Mi sistema para que la deuda no me coma
Ignorar deuda conscientemente no significa ser un anarquista del código. Requiere un sistema. El caos es tu enemigo. El mío es simple:
1. Documentar TODO: La deuda que no se apunta, se olvida. Y la deuda olvidada es la que se pudre. Uso etiquetas en los tickets (`tech-debt`, `refactor-needed`) o tengo un simple archivo `TECH_DEBT.md` en el repositorio.
## TECH_DEBT.mdMódulo de Reportes (report-generator.js) - **Deuda:** Lógica de cálculo duplicada con el módulo de analytics. - **Razón:** Se necesitaba lanzar rápido para una demo a un cliente clave. - **Disparador para pagar:** Si más de 3 clientes usan activamente los reportes o antes de añadir nuevos tipos de reportes. ```
2. Establecer disparadores (Triggers): Nunca digo "lo arreglaremos luego". Digo "lo arreglaremos CUANDO...". El "cuando" es un evento de negocio medible: "...cuando lleguemos a 1,000 usuarios de pago", "...cuando la latencia de esta API supere los 500ms", "...antes de empezar a construir la v2 de esta feature".
3. Aislar la deuda: Intento que el código "rápido y sucio" viva en su propio módulo, bien aislado del código core. Así, la infección no se propaga. Es como tener un garaje desordenado; mientras el desorden no invada la casa, puedes vivir con ello.
Al final, la deuda técnica no es una cuestión moral, es una herramienta. La diferencia entre un amateur y un profesional no es quién escribe código perfecto siempre (nadie lo hace), sino quién entiende qué compromisos está haciendo, por qué los está haciendo y cómo planea gestionarlos.
Por eso duermo tranquilo. No porque mi código sea perfecto, sino porque sé exactamente dónde no lo es, y tengo un plan para ello.