Lo que hicimos esta semana: por qué el mantenimiento invisible decide el destino de tu producto digital

Esta semana no lanzamos ninguna feature nueva en rizo.ma. No rediseñamos ninguna pagina. No añadimos ninguna funcionalidad. No hubo capturas de pantalla espectaculares para mostrar en una demo, ni metricas de engagement que presentar en una reunion de directorio. Sin embargo, lo que hicimos probablemente fue mas importante que cualquier feature que pudieramos haber construido.

En siete dias, ejecutamos ocho intervenciones de mantenimiento sobre nuestro propio sitio web corporativo: self-hosteamos las fuentes tipograficas que antes cargabamos desde Google Fonts, configuramos cache inmutable para assets estaticos con fingerprint, resolvimos siete errores de tipos que se habian acumulado en el chequeo estatico de Astro, añadimos atributos is:inline a scripts que los requerian silenciosamente, eliminamos variables sin usar, codigo muerto y atributos HTML4 deprecados, migramos la API de cookies de Supabase a la version no deprecada, reemplazamos un tipo deprecado de React, y limpiamos referencias a empresas especificas que ya no eran precisas.

Ninguno de estos cambios altera lo que el usuario ve. Todos ellos alteran lo que el usuario experimenta: la velocidad de carga, la confiabilidad del sistema de autenticacion, la ausencia de errores sutiles que podrian manifestarse en produccion, la capacidad de nuestro equipo para trabajar eficientemente sobre este codigo en el futuro. Esto es mantenimiento invisible. Y es, argumentamos en este articulo, una de las decisiones estrategicas mas subestimadas en la gestion de productos digitales.

La deuda tecnica como riesgo organizacional

La metafora de la deuda tecnica, acuñada por Ward Cunningham en 1992, se ha convertido en parte del vocabulario cotidiano del desarrollo de software. Pero como ocurre con muchas metaforas que se popularizan, su significado se ha diluido. En la mayoria de las organizaciones, “deuda tecnica” se entiende como “cosas que los desarrolladores quieren arreglar pero que no son urgentes”. Esta interpretacion es peligrosamente incorrecta. La deuda tecnica no es un problema de ingenieria; es un riesgo organizacional que se acumula de forma invisible hasta que se manifiesta de forma visible, generalmente en el peor momento posible.

La evidencia empirica respalda esta afirmacion con numeros concretos. Besker, Martini y Bosch (2019) condujeron un estudio longitudinal con 43 desarrolladores en el que encontraron que, en promedio, los equipos de desarrollo desperdician el 23% de su tiempo laboral debido a deuda tecnica. No se trata de tiempo dedicado a escribir codigo nuevo que resulta ineficiente; se trata de tiempo gastado en navegar codigo confuso, realizar testing adicional para compensar fragilidades conocidas, depurar problemas que no deberian existir, y lidiar con dependencias que se resisten a colaborar. Casi una cuarta parte del tiempo productivo de un equipo de ingenieria, evaporado en friccion evitable.

Un estudio posterior de mayor escala, InsighTD, una familia de encuestas con 653 profesionales de seis paises, confirmo y extendio estos hallazgos. Ramac et al. (2021) reportaron que en promedio el 25% del esfuerzo de desarrollo se desperdicia en problemas causados por deuda tecnica, y que las consecuencias mas citadas por los profesionales son: retrasos en entregas, baja mantenibilidad del sistema, y retrabajo. Notablemente, la causa mas citada de acumulacion de deuda tecnica fue la presion de tiempo o plazos de entrega, exactamente el tipo de presion que lleva a las organizaciones a priorizar features sobre mantenimiento.

Pero quiza lo mas revelador es lo que Besker, Ghanbari, Martini y Bosch (2020) descubrieron cuando investigaron el impacto de la deuda tecnica en la moral de los desarrolladores. Encontraron que la presencia de deuda tecnica reduce la moral de los equipos de desarrollo, lo que a su vez reduce aun mas su productividad, creando un ciclo vicioso. Sin embargo, tambien encontraron que la gestion activa de deuda tecnica, es decir, exactamente el tipo de trabajo que hicimos esta semana, tiene un efecto positivo en la moral y, por extension, en la productividad. Mantener no es solo reparar el producto; es reparar la relacion del equipo con el producto.

Y cuando la deuda tecnica no se gestiona, las consecuencias trascienden la productividad individual. Ramasubbu y Kemerer (2016) analizaron datos longitudinales del ciclo de vida completo de un sistema empresarial desplegado en 48 organizaciones diferentes durante 10 años, y establecieron que la deuda tecnica disminuye la confiabilidad de los sistemas empresariales de forma medible y progresiva. Es decir, no estamos hablando de incomodidad para los desarrolladores; estamos hablando de sistemas que se vuelven menos confiables con el tiempo si no se mantienen activamente.

Cada API deprecada en tu codebase es un reloj corriendo hacia atras. Cada recurso que bloquea el rendering es ingreso potencial perdido. Cada error de tipos es un incidente futuro en produccion esperando el momento adecuado para manifestarse. La deuda tecnica no es una molestia de ingenieria. Es riesgo organizacional acumulado.

Lo que hicimos y por que importa

Permitanme recorrer cada una de las intervenciones que realizamos esta semana, no como un changelog tecnico sino como un ejercicio de traduccion: de lenguaje de ingenieria a consecuencia de negocio.

Self-hosting de fuentes tipograficas

Nuestro sitio cargaba las fuentes tipograficas desde Google Fonts, un servicio CDN gratuito que aloja miles de familias tipograficas. Es la opcion por defecto para la mayoria de los sitios web, y durante años fue la recomendacion estandar: rapido, facil, y alguien mas se encarga del hosting. Pero ese modelo tiene un costo oculto.

Cuando un navegador carga una pagina que depende de Google Fonts, necesita hacer una peticion adicional a un servidor externo antes de poder renderizar el texto. Esa peticion introduce una dependencia externa en una ruta critica: si el CDN de Google experimenta latencia, si cambia su API, si el usuario esta en una red lenta, el First Contentful Paint y el Largest Contentful Paint de nuestra pagina se degradan. No porque nuestro servidor sea lento, sino porque introdujimos una dependencia externa en el momento mas critico de la experiencia del usuario: los primeros milisegundos.

Descargamos los archivos de fuentes, los servimos localmente con font-display: swap para evitar flash de texto invisible, y añadimos preload hints para que el navegador comience a descargar las fuentes antes de necesitarlas. Hicimos lo mismo para nuestra sub-aplicacion climalab. Luego limpiamos todas las referencias muertas a Google Fonts que habian quedado dispersas en el codigo.

La consecuencia de negocio: eliminamos una dependencia externa sobre la que no tenemos control en la ruta critica de rendering. Si mañana Google modifica su servicio de Fonts, nuestro sitio no se entera. Y los tiempos de carga mejoran porque el navegador no necesita resolver DNS, establecer conexion TLS e intercambiar datos con un servidor externo antes de mostrar texto. Stadnik y Nowak (2017) demostraron que los tiempos promedio de carga tienen un impacto directo en la tasa de conversion y la satisfaccion del cliente en plataformas de comercio electronico. Cada milisegundo cuenta, y cada dependencia externa en la ruta critica es un milisegundo que no controlamos.

Cache inmutable para assets estaticos

Astro, nuestro framework de frontend, genera assets estaticos (JavaScript, CSS, imagenes procesadas) con nombres que incluyen un hash del contenido. Si el archivo cambia, el hash cambia, y por tanto el nombre cambia. Esto significa que un archivo con un nombre especifico tiene un contenido garantizado como inmutable: si el nombre es el mismo, el contenido es identico.

Sin embargo, sin la configuracion adecuada de headers HTTP, el navegador no sabe esto. En cada visita subsecuente, el navegador pregunta al servidor “¿este archivo cambio?” y espera la respuesta antes de usar la version cacheada. Es una peticion innecesaria que introduce latencia en cada carga de pagina para visitantes recurrentes.

Configuramos Cache-Control: public, max-age=31536000, immutable para todos los assets bajo /_astro/ en nuestra configuracion de Vercel. Esto le dice al navegador: “este archivo no va a cambiar nunca. Usalo directamente del cache local sin preguntar.” Para visitantes que regresan, la carga es practicamente instantanea para estos recursos.

La consecuencia de negocio: los visitantes recurrentes experimentan un sitio significativamente mas rapido. En un contexto donde nuestro sitio es una herramienta de conversion de leads, donde ofrecemos assessments, calculadoras y diagnosticos interactivos, la velocidad de carga de paginas subsecuentes afecta directamente la probabilidad de que un visitante complete el funnel. Un sitio que se siente instantaneo genera confianza. Un sitio que se siente lento genera abandono.

Resolucion de errores de tipos acumulados

Astro incluye un chequeo de tipos estatico (astro check) que analiza el codigo y detecta inconsistencias de tipos antes de que lleguen a produccion. Habiamos acumulado siete errores en este chequeo a lo largo de meses de desarrollo. Ninguno causaba un fallo visible en produccion porque Astro compila el codigo de todas formas, pero cada uno representaba un sitio donde el comportamiento del programa en runtime podria diferir de lo que el desarrollador esperaba.

Estos errores incluian anotaciones de tipos incorrectas, imports no utilizados, y tipos de props que no coincidian con lo que los componentes realmente esperaban. Son el tipo de problema que no se manifiesta hasta que alguien modifica el componente y asume que los tipos documentados son los tipos reales, introduce un cambio basado en esa suposicion, y el sistema se comporta de forma inesperada.

La consecuencia de negocio: eliminar errores de tipos no es perfeccionismo; es prevencion de incidentes. Cada error de tipos resuelto ahora es una sesion de depuracion que no ocurrira en el futuro. En un equipo pequeño donde el tiempo de cada persona es critico, prevenir una hora de depuracion tiene un valor desproporcionado. Y en un sistema que maneja datos de leads, inscripciones a eventos y comunicacion automatizada por email, un bug sutil en un componente puede tener consecuencias que van desde un email malformado hasta una inscripcion perdida.

Atributos `is:inline` en scripts

Astro procesa los scripts de forma especial: los agrupa, optimiza y gestiona sus dependencias automaticamente. Pero cuando un script tiene ciertos atributos que requieren ejecucion en un contexto especifico, Astro necesita saber que ese script debe mantenerse inline, sin procesamiento. El atributo is:inline comunica esta intencion explicitamente.

Sin este atributo, el comportamiento del script es indefinido: podria funcionar correctamente, o podria ser procesado de una forma que rompa su funcionalidad. Habiamos identificado scripts en nuestro codebase que tenian atributos que requerian is:inline pero no lo declaraban. Funcionaban por casualidad, no por diseño.

La consecuencia de negocio: “funciona por casualidad” es una de las frases mas peligrosas en ingenieria de software. Significa que cualquier actualizacion del framework, cualquier cambio en la configuracion del build, cualquier refactorizacion de la pagina podria romper la funcionalidad sin que nadie entienda por que. Explicitar el contrato entre el codigo y el framework elimina una categoria completa de fallos potenciales.

Eliminacion de codigo muerto, variables sin usar y atributos HTML4 deprecados

A lo largo de meses de desarrollo iterativo, nuestro codebase habia acumulado artefactos de versiones anteriores: variables declaradas pero nunca referenciadas, funciones definidas pero nunca invocadas, atributos HTML que pertenecian a la especificacion HTML4 y ya no tienen efecto en navegadores modernos. Ninguno de estos artefactos causaba un error visible, pero todos tenian un costo.

Kupoluyi et al. (2022) demostraron que la eliminacion de codigo muerto en JavaScript puede acelerar la carga de paginas entre un 25% y un 30%, gracias a la combinacion de menor uso de CPU y menor uso de ancho de banda. Si bien nuestro caso no involucraba volumenes de codigo muerto comparables a los de su estudio, el principio aplica directamente: cada byte innecesario que el navegador descarga, parsea y ejecuta es un byte que degrada la experiencia del usuario sin aportar valor alguno.

Pero el costo del codigo muerto no es solo de performance. El codigo muerto confunde a los desarrolladores futuros, sean humanos o asistentes de IA, que intentan entender el sistema. Una variable declarada sugiere que se usa en algun lugar. Una funcion definida sugiere que tiene un proposito. Un atributo HTML presente sugiere que tiene un efecto. Cuando estas suposiciones son falsas, el desarrollador pierde tiempo investigando fantasmas, o peor, toma decisiones basadas en señales incorrectas. Las herramientas de analisis de codigo reportan falsos positivos, los reviews de codigo se detienen en lineas irrelevantes, y la complejidad cognitiva del sistema crece sin que su funcionalidad crezca.

La consecuencia de negocio: un codebase limpio es un codebase donde el equipo puede moverse rapido con confianza. Un codebase con artefactos muertos es un codebase donde cada modificacion requiere arqueologia antes de ingenieria.

Migracion de la API de cookies de Supabase

Nuestro sistema de autenticacion utiliza Supabase, y nuestra integracion server-side dependia de la API de cookies get/set/remove, que gestiona cookies individuales. Supabase depreco esta API en favor de getAll/setAll, que opera sobre lotes de cookies. La API antigua sigue funcionando, por ahora. Pero “por ahora” es exactamente la frase que precede a “y un viernes a las 11pm dejo de funcionar”.

Raemaekers, Deursen y Visser (2017) realizaron un estudio empirico sobre mas de 100,000 archivos jar en Maven Central y encontraron que aproximadamente un tercio de todas las releases de librerias introducen al menos un cambio que rompe compatibilidad hacia atras, y que estos cambios tienen un impacto significativo en los clientes que usan la funcionalidad modificada. Las APIs deprecadas son, por definicion, candidatas a ser eliminadas en una version futura. La pregunta no es si se eliminaran, sino cuando.

Migrar proactivamente, cuando nosotros elegimos el momento y tenemos tiempo para testear, es fundamentalmente diferente a migrar reactivamente, cuando el sistema se rompe en produccion y el equipo descubre a las once de la noche que la API que usaban ya no existe. La primera es gestion de riesgos. La segunda es gestion de crisis.

La consecuencia de negocio: nuestro sistema de autenticacion es la puerta de entrada al portal de colaboradores, al sistema de inscripcion a eventos, y al panel de administracion. Si la autenticacion falla, todo lo que esta detras de ella se vuelve inaccesible. Migrar la API de cookies proactivamente elimina un escenario de fallo que habria afectado directamente a nuestros clientes y colaboradores.

Migracion de React.FormEvent a SyntheticEvent

Un cambio menor en apariencia: reemplazar una referencia de tipo deprecada en React por su equivalente actual. React.FormEvent sigue funcionando, pero el equipo de React lo ha marcado como deprecado, lo que significa que su comportamiento podria cambiar o su soporte podria eliminarse en versiones futuras.

La consecuencia de negocio: identica al caso anterior, pero a menor escala. Cada tipo deprecado es una pequeña bomba de tiempo. Desactivarlas una por una, en momentos de calma, es infinitamente preferible a descubrirlas todas juntas cuando actualizas React a una version major y la mitad de tu codebase produce errores de compilacion.

Limpieza de referencias a empresas especificas

Nuestro contenido mencionaba empresas especificas como ejemplos de clientes o casos de uso. Estas referencias se habian vuelto imprecisas con el tiempo. Las eliminamos para mantener la integridad del contenido.

La consecuencia de negocio: la credibilidad de un sitio web corporativo depende de la precision de su contenido. Una referencia incorrecta a una empresa puede generar confusion, dañar relaciones comerciales, o simplemente proyectar una imagen de descuido. En un sitio que argumenta que la transformacion organizacional requiere atencion al detalle, cada detalle cuenta.

Por que las organizaciones no hacen esto

Si el mantenimiento invisible es tan importante, ¿por que la mayoria de las organizaciones lo posterga indefinidamente? La respuesta no es ignorancia ni negligencia; es una falla sistemica en como las organizaciones evaluan y priorizan el trabajo.

El primer problema es de visibilidad. El mantenimiento invisible no produce capturas de pantalla. No genera metricas de engagement. No tiene un before/after que impresione en una presentacion. Cuando un product owner presenta los resultados del sprint, “migramos la API de cookies de Supabase a la version no deprecada” no genera el mismo entusiasmo que “lanzamos el nuevo dashboard de analiticas”. Sin embargo, el dashboard de analiticas funciona gracias a que la autenticacion funciona, y la autenticacion funciona gracias a que alguien se aseguro de que la API de cookies no estuviera a punto de quebrarse.

El segundo problema es de incentivos. En la mayoria de las organizaciones, los desarrolladores son evaluados por features entregadas, no por incidentes prevenidos. Nadie recibe un bonus por “esa vez que el sistema no se cayo porque migraste una dependencia deprecada antes de que se eliminara”. La ausencia de problemas es invisible; solo la presencia de problemas es notable. Este sesgo sistemico hacia lo visible sobre lo importante crea una estructura de incentivos que penaliza el mantenimiento y recompensa la acumulacion de deuda tecnica.

El tercer problema es temporal. El costo del mantenimiento diferido no es inmediato. Cuando decides posponer la migracion de una API deprecada, nada se rompe hoy. El beneficio de posponer es inmediato y concreto: esas horas se usan para construir una feature. El costo de posponer es futuro e incierto: quiza la API se elimine en seis meses, quiza en dos años, quiza nunca. Esta asimetria temporal favorece sistematicamente la postergacion.

El cuarto problema es cognitivo. Los seres humanos somos naturalmente malos evaluando riesgos de baja probabilidad y alto impacto. La probabilidad de que una API deprecada especifica se rompa esta semana especifica es baja. Pero la probabilidad de que al menos una de las multiples APIs deprecadas en un codebase se rompa en algun momento del proximo año es alta. Evaluamos cada riesgo individual como bajo y, al hacerlo, subestimamos el riesgo agregado.

El resultado de estas cuatro fuerzas es predecible y universal: las organizaciones acumulan deuda tecnica invisible hasta que algo se rompe publicamente. Y cuando se rompe, la respuesta es un esfuerzo heroico de reparacion que consume mas recursos que el mantenimiento preventivo que se postergo, seguido de una promesa de “ahora si vamos a dedicar tiempo a limpiar”, que se cumple durante un sprint y luego se abandona en cuanto aparece la siguiente feature urgente.

El costo de no mantener

Describamos con precision lo que ocurre cuando el mantenimiento invisible se posterga sistematicamente. No en teoria, sino en la practica cotidiana de un producto digital.

Los scores de Lighthouse bajan silenciosamente. Nadie los monitorea porque no estan en el dashboard del product owner. Un dia, alguien corre un audit y descubre que el performance score bajo de 95 a 72 en los ultimos seis meses. Nadie sabe exactamente cuando ni por que, porque el deterioro fue gradual: un script adicional aqui, una fuente no optimizada alla, un componente que carga datos innecesarios en el viewport inicial. Cada degradacion individual fue insignificante; la suma es significativa.

Las APIs deprecadas dejan de funcionar sin aviso. Un proveedor publica una version major de su libreria y elimina la API que marcaron como deprecada hace 18 meses. Tu sistema funciona perfectamente el jueves. El viernes, un deploy automatico actualiza la dependencia y el sistema de autenticacion deja de funcionar. El equipo que deberia estar construyendo features esta ahora en modo bombero, intentando entender una migracion que podrian haber hecho con calma hace meses.

Las vulnerabilidades de seguridad se acumulan. Las dependencias desactualizadas no solo pierden funcionalidad; acumulan vulnerabilidades conocidas que se publican en bases de datos como CVE. Un atacante no necesita descubrir una vulnerabilidad nueva en tu sistema; solo necesita verificar que usas una version de una libreria con una vulnerabilidad documentada. Cada dependencia sin actualizar es una puerta que sabes que esta desbloqueada pero decides no cerrar porque “nadie ha intentado entrar”.

La productividad del equipo se degrada de forma invisible. Los desarrolladores no reportan “hoy perdi una hora navegando codigo muerto”. Simplemente tardan mas. Las estimaciones se inflan porque los desarrolladores internalizan la friccion como una constante del sistema. “Asi de complejo es nuestro codebase” se convierte en la explicacion por defecto, cuando la explicacion real es “nuestro codebase tiene una capa de complejidad accidental que nadie ha limpiado”.

Y quiza lo mas insidioso: el conocimiento institucional se erosiona. Cuando un desarrollador deja el equipo, el nuevo integrante hereda un codebase donde las señales no coinciden con la realidad. Hay variables que sugieren funcionalidad que no existe. Hay imports que apuntan a modulos que ya no se usan. Hay patrones de codigo que reflejan decisiones de hace dos años que ya no aplican. El tiempo de onboarding se multiplica, y la probabilidad de introducir bugs por malentender el sistema se incrementa.

Practicamos lo que predicamos

Hay algo que debemos hacer explicito en este punto: el sitio del que estamos hablando es nuestro propio sitio. rizo.ma es el sitio web de Rizoma, nuestra consultora de transformacion organizacional. No es el sitio de un cliente. No es un proyecto externo. Es nuestra carta de presentacion digital.

Esta transparencia es deliberada. En Rizoma trabajamos con organizaciones que estan en proceso de transformacion digital, y una de las cosas que predicamos constantemente es que la transformacion no es un evento sino un proceso continuo. Que la agilidad no es adoptar un framework sino cultivar la capacidad de adaptacion. Que la calidad no es un checklist de lanzamiento sino una practica diaria.

Si nuestro propio sitio cargara lento porque no migramos las fuentes tipograficas, si nuestro sistema de autenticacion se rompiera porque no migramos una API deprecada, si nuestro codebase estuviera lleno de codigo muerto que nadie se molesto en limpiar, ¿con que autoridad podriamos hablar de excelencia operativa a nuestros clientes?

El producto digital de una consultora de transformacion no es solo un canal de comunicacion; es una demostracion de capacidad. Cada decision tecnica que tomamos en rizo.ma refleja los principios que llevamos a nuestros clientes. Self-hostear fuentes no es solo una optimizacion de performance; es una decision de reducir dependencias externas en sistemas criticos, algo que recomendamos a nuestros clientes todo el tiempo. Migrar APIs deprecadas proactivamente no es solo higiene de codigo; es gestion de riesgos, algo que enseñamos en nuestros talleres de transformacion.

Esto no significa que nuestro sitio sea perfecto. Significa que dedicamos tiempo deliberado a mantenerlo, que tratamos el mantenimiento como inversion estrategica y no como tarea de relleno, y que estamos dispuestos a documentar publicamente lo que hacemos y por que. La credibilidad se construye con consistencia entre lo que dices y lo que haces, no con discursos sobre excelencia mientras tu infraestructura se deteriora.

Como incorporar mantenimiento invisible en la cadencia organizacional

La pregunta practica es: ¿como logras que el mantenimiento invisible ocurra de forma sistematica en una organizacion donde las fuerzas naturales conspiran contra el? Nuestra experiencia, tanto en nuestro propio producto como en los de nuestros clientes, sugiere varias practicas concretas.

Dedicar tiempo regular y protegido. No “cuando tengamos tiempo” ni “al final del sprint si sobra capacidad”. Tiempo real, bloqueado, no negociable. En nuestro caso, dedicamos una semana completa. No todas las organizaciones pueden hacer esto con la misma frecuencia, pero la proporcion importa. Si el 100% de tu capacidad esta asignada a features, el 0% de tu capacidad esta asignada a la salud de tu producto. Y un producto sin mantenimiento es un producto con fecha de expiracion.

Tratar el mantenimiento como reduccion de riesgo, no como costo. El lenguaje importa. Cuando presentas mantenimiento como “limpieza de codigo”, suena discrecional. Cuando lo presentas como “migracion de una API que dejara de funcionar y rompera nuestro sistema de autenticacion”, suena urgente. No es manipulacion; es precision. El mantenimiento invisible ES reduccion de riesgo, y deberia comunicarse como tal.

Medir metricas de salud del producto. Lo que no se mide no se gestiona. Incorpora Lighthouse scores, cobertura de tipos, frescura de dependencias, y cantidad de warnings en el build como metricas de primer nivel del producto. No como metricas de ingenieria que viven en un dashboard que solo los desarrolladores ven, sino como metricas del producto que se reportan junto con la tasa de conversion y el engagement. Si tu Lighthouse score baja de 95 a 72 y nadie lo nota, tienes un problema de visibilidad, no un problema de performance.

Hacer visible lo invisible. Este articulo es un ejemplo de esa practica. Documentar publicamente el mantenimiento que realizamos no solo genera accountability interna; tambien educa a nuestros clientes y a nuestra audiencia sobre la importancia de este trabajo. Si solo hablaramos de features nuevas, estariamos perpetuando la narrativa de que lo unico que importa en un producto digital es lo que se añade, no lo que se cuida.

Automatizar la deteccion. Configura herramientas que detecten automaticamente dependencias deprecadas, errores de tipos, codigo muerto, y problemas de performance. En nuestro caso, usamos astro check para tipos, SonarCloud para analisis de codigo, y Lighthouse para performance. Estas herramientas no resuelven los problemas, pero los hacen visibles, que es el primer paso necesario para que alguien los resuelva.

Vincular el mantenimiento con la velocidad de desarrollo. La proxima vez que un stakeholder pregunte por que una feature tarda mas de lo esperado, invitalo a observar cuanto tiempo del desarrollo se gasta navegando complejidad accidental. Los datos de Besker, Martini y Bosch (2019) sobre el 23% de tiempo desperdiciado son un argumento poderoso: si puedes reducir ese porcentaje dedicando tiempo a mantenimiento, el resultado neto es mas features entregadas, no menos. El mantenimiento no compite con el desarrollo de features; lo habilita.

Crear cultura de ownership sobre el codebase. En equipos donde el codebase se percibe como “algo que heredamos” o “algo que alguien mas deberia arreglar”, el mantenimiento no ocurre. En equipos donde el codebase se percibe como “nuestro sistema, nuestra responsabilidad”, el mantenimiento es natural. Esta es una dimension cultural que ningun proceso puede sustituir pero que las practicas correctas pueden cultivar. Cuando un desarrollador ve codigo muerto y lo elimina sin que nadie se lo pida, eso es ownership. Cuando lo ve y lo ignora porque “no esta en el ticket”, eso es un sintoma organizacional.

Lo invisible sostiene lo visible

Todo lo que un usuario experimenta cuando visita rizo.ma, la velocidad con la que la pagina renderiza, la confiabilidad del sistema de autenticacion cuando un colaborador inicia sesion, la ausencia de errores cuando alguien completa un assessment o calcula el costo del no-cambio, esta construido sobre una capa de trabajo que el usuario nunca ve. Esa capa es el mantenimiento invisible.

Las fuentes que cargan rapido estan ahi porque alguien decidio self-hostearlas. Los assets que aparecen instantaneamente en visitas recurrentes estan ahi porque alguien configuro los headers de cache correctos. La autenticacion que funciona sin sorpresas esta ahi porque alguien migro la API antes de que se quebrara. El codebase que permite al equipo moverse con confianza esta ahi porque alguien elimino el ruido acumulado.

Las organizaciones que entienden esto construyen productos que duran. Productos que mejoran con el tiempo en lugar de deteriorarse. Productos donde cada sprint construye sobre una base solida en lugar de sobre una capa de parches precarios. Productos donde el equipo de desarrollo dedica su tiempo a crear valor en lugar de a gestionar las consecuencias de valor no creado.

Las organizaciones que no entienden esto construyen productos que eventualmente, inevitablemente, se quiebran. No con un estallido dramatico que todos recuerdan, sino con una degradacion lenta que nadie nota hasta que la acumulacion de pequeños deterioros produce un fallo visible. Y en ese momento, el costo de reparar es ordenes de magnitud mayor que el costo de mantener.

Esta semana no lanzamos ninguna feature nueva. Pero esta semana, nuestro producto es mas rapido, mas confiable, mas mantenible, y mas resiliente que la semana pasada. Eso no aparece en ninguna metrica de engagement. Aparece en algo mas importante: la confianza de que cuando lancemos la proxima feature, el sistema que la sostiene va a funcionar.

Lo invisible sostiene lo visible. Las organizaciones que internalizan esta verdad no solo construyen mejores productos. Construyen mejores organizaciones.

Referencias

Besker, T., Martini, A. & Bosch, J. (2018). Technical Debt Cripples Software Developer Productivity: A Longitudinal Study on Developers’ Daily Software Development Work. International Conference on Technical Debt (TechDebt), ICSE. DOI: 10.1145/3194164.3194178
Besker, T., Martini, A. & Bosch, J. (2019). Software developer productivity loss due to technical debt — A replication and extension study examining developers’ development work. Journal of Systems and Software, 156, 41-61. DOI: 10.1016/j.jss.2019.06.004
Besker, T., Ghanbari, H., Martini, A. & Bosch, J. (2020). The influence of Technical Debt on software developer morale. Journal of Systems and Software, 167, 110586. DOI: 10.1016/j.jss.2020.110586
Kupoluyi, J., Chaqfeh, M., Varvello, M., Coke, R., Hashmi, W., Subramanian, L. & Zaki, Y. (2022). Muzeel: Assessing the Impact of JavaScript Dead Code Elimination on Mobile Web Performance. ACM Internet Measurement Conference (IMC). DOI: 10.1145/3517745.3561427
Raemaekers, S., Deursen, A. & Visser, J. (2017). Semantic versioning and impact of breaking changes in the Maven repository. Journal of Systems and Software, 129, 140-158. DOI: 10.1016/j.jss.2016.04.008
Ramac, R., Mandic, V., Tausan, N., Rios, N., Freire, S., Perez, B., … & Spinola, R. (2021). Prevalence, Common Causes and Effects of Technical Debt: Results from a Family of Surveys with the IT Industry. Journal of Systems and Software, 184, 111114. DOI: 10.1016/j.jss.2021.111114
Ramasubbu, N. & Kemerer, C. (2016). Technical Debt and the Reliability of Enterprise Software Systems: A Competing Risks Analysis. Management Science, 62(5), 1487-1510. DOI: 10.2139/ssrn.2523483
Stadnik, W. & Nowak, Z. (2017). The Impact of Web Pages’ Load Time on the Conversion Rate of an E-Commerce Platform. Information Systems Architecture and Technology, 336-345. DOI: 10.1007/978-3-319-67220-5_31