¿Cómo decides entre pagar deuda técnica y lanzar una funcionalidad?

#Replantea la pregunta antes de responderla

El planteamiento binario — deuda contra funcionalidad — suele ser la trampa, y rechazarlo en voz alta es lo primero que debería hacer una respuesta senior. El trabajo no es tomar partido en una discusión de valores ("el código limpio importa" contra "hay que lanzar rápido"); es convertir una tensión vaga en una decisión de asignación de capacidad con números. Dilo explícitamente en la entrevista: "no lo pienso como deuda contra funcionalidad, lo pienso como cuál de las dos tiene mejor retorno este trimestre, y así es como lo mediría."

#Categoriza la deuda primero

No toda la deuda es igual, y tratarla como una pila sin diferenciar es por lo que estas discusiones dan vueltas en círculo. Yo la clasifico en tres grupos: deuda que asumimos a sabiendas para cumplir una fecha real, con el atajo documentado en algún lugar; deuda que no sabíamos que era deuda cuando la escribimos, porque las restricciones cambiaron debajo de nosotros; y deuda que en realidad es una preferencia disfrazada de problema — código que funciona bien y que solo se vería más bonito si se refactorizara. Solo las dos primeras merecen gastar un debate; la tercera es donde muchos ingenieros junior-a-medio malgastan capital político.

#Ponle precio en la moneda del negocio

Convierte la deuda en tres números que un PM o un EM puedan usar sin necesitar un título en ciencias de la computación: el impuesto de velocidad (cuántos puntos de historia extra cuesta cada funcionalidad en esa área por culpa del atajo), el costo de incidentes (cuántas alertas, rollbacks u hotfixes se remontan a él en los últimos dos trimestres) y el impuesto de incorporación (cuánto tarda una persona nueva en ser productiva de forma segura tocando ese código). Ejemplo concreto: una capa de red compartida que parseaba JSON sin tipos estaba causando aproximadamente una regresión que provocaba crashes por cada ciclo de release, y añadía un día a cada funcionalidad que tocara un endpoint nuevo — eso no es "este código es feo", es un costo recurrente y cuantificado con un número encima.

#Haz el trade-off explícito con los stakeholders

Lleva una página, no un mensaje de Slack: el costo de no hacer nada durante los próximos dos trimestres, contra el costo de un pago acotado de una o dos semanas, en términos que los stakeholders ya usan — fechas de entrega, número de incidentes, carga de guardia. Negocia como "esta funcionalidad se retrasa cuatro días" o "lanzamos un alcance reducido en la fecha original", nunca como una solicitud abierta de "déjame refactorizar esto". Las solicitudes abiertas pierden siempre contra fechas de funcionalidades concretas, y con razón — nadie puede evaluar una solicitud abierta.

#Prefiere pagar intereses en vez de condonar toda la deuda de golpe

Defiende el pago incremental integrado en cada funcionalidad que toque esa área — la regla del boy-scout aplicada deliberadamente — más franjas pequeñas y dedicadas de forma periódica para las piezas estructurales, en vez de pedir siempre un trimestre entero de reescritura como bloque aparte. Las reescrituras como bloque aparte son difíciles de vender, compiten directamente contra los compromisos del roadmap, y tienen fama bien ganada de alargarse. Fui desgastando una capa de bridging de Objective-C heredada, módulo por módulo durante un año, siempre enganchada a trabajo de funcionalidades que ya la tocaba, y nunca fue una línea que alguien tuviera que defender por sí sola.

#Sabe dónde está la línea dura

Parte de la deuda no es en absoluto una cuestión de gusto de desarrollador — es un riesgo de negocio, y tratarla como una negociación es el instinto equivocado. Vulnerabilidades de seguridad, código propenso a crashes en un flujo de pago o checkout, brechas de accesibilidad con exposición legal, cualquier cosa que arriesgue un rechazo en la App Store — para esto, el trabajo es escalarlo como una declaración de riesgo a quien sea dueño de ese riesgo, no relitigarlo como una opinión técnica, y estar dispuesto a bloquear un release por ello.