En 1992, el programador Ward Cunningham —el mismo que años después inventaría el wiki— escribió un informe para un cliente del sector financiero explicando por qué hacía falta parar a reescribir parte del código antes de seguir añadiendo funciones nuevas. Para que la idea calara en alguien sin formación técnica, usó una comparación que ha sobrevivido más de tres décadas: "lanzar la primera versión del código es como entrar en deuda. Un poco de deuda acelera el desarrollo, siempre que se devuelva pronto con una reescritura". Esa frase es el origen real del término "deuda técnica", y merece la pena volver a ella porque el significado se ha ido desdibujando con el uso.
Lo que Cunningham quería decir (y lo que normalmente se entiende mal)
Hoy "deuda técnica" se usa casi como sinónimo de "código malo", pero esa no era la idea original. Para Cunningham, la deuda técnica es la distancia entre lo que el equipo entiende hoy del problema que está resolviendo y lo que el código actual refleja de ese entendimiento. Esa distancia no aparece por escribir mal: aparece porque el conocimiento del dominio avanza más rápido que el código, algo que pasa en cualquier proyecto que dure más de unas semanas.
La consecuencia práctica de esta distinción importa: no toda la deuda técnica es un error que alguien cometió. Parte de ella es simplemente el coste normal de haber aprendido algo nuevo sobre el problema después de haber escrito el código.
Los cuatro tipos de deuda técnica
Martin Fowler propuso más adelante una forma útil de clasificarla, cruzando dos preguntas: ¿fue una decisión consciente? y ¿fue una decisión razonable en su momento?
- Deliberada y prudente: "sabemos que este atajo no es ideal, pero entregar ahora vale más que hacerlo perfecto, y ya sabemos cómo arreglarlo después". Es deuda tomada con conocimiento de causa, la versión más sana.
- Deliberada e imprudente: "no tenemos tiempo para hacerlo bien, ya lo arreglaremos" sin ningún plan real de cuándo o cómo. Es la que más se acumula sin control.
- Inadvertida y prudente: se tomó la mejor decisión posible con la información disponible en ese momento, y solo en retrospectiva —con más experiencia o más contexto— se ve que había una forma mejor.
- Inadvertida e imprudente: errores de diseño que ni siquiera se identifican como deuda hasta que causan un problema real, normalmente por desconocimiento de buenas prácticas básicas.
Distinguir estos cuatro casos importa porque la respuesta correcta es distinta en cada uno: la deliberada y prudente solo necesita un recordatorio de cuándo pagarla; la inadvertida y prudente ni siquiera es un fallo de nadie, es aprendizaje normal del proyecto.
Cómo gestionarla sin frenar el desarrollo
La respuesta habitual —"paremos todo un sprint para pagar deuda técnica"— casi nunca sobrevive a la primera fecha límite urgente. Funciona mejor tratarla como un flujo continuo en vez de un evento puntual:
Hacerla visible. Un backlog técnico compartido, aunque sea una lista simple, evita que la deuda viva solo en la cabeza de quien la creó y se pierda cuando esa persona cambia de equipo.
La regla del boy scout. Dejar el código un poco mejor de como se encontró cada vez que se toca, en vez de perseguir "dejarlo perfecto" de una sola vez. Un archivo que se toca diez veces al año mejora solo con pequeñas correcciones acumuladas; uno que no se toca nunca no necesita esa inversión.
Priorizar por interés, no por antigüedad. No toda la deuda pesa igual: la que está en el camino crítico del producto —esa función que se toca cada semana y cada vez cuesta más entenderla— genera más "interés" que una parte del sistema estable que nadie modifica desde hace un año. Pagar primero la que más frena el trabajo diario, no la más vieja.
Cuándo tiene sentido no pagarla
No toda deuda merece devolverse. Si una funcionalidad va a desaparecer pronto, o vive en una parte del sistema con tráfico y cambios mínimos, el coste de refactorizarla puede ser mayor que el de convivir con ella. La pregunta útil no es "¿esto está sucio?", sino "¿el coste de mantenerlo así sigue siendo menor que el coste de arreglarlo?". En cuanto deja de serlo, es el momento de pagar.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!