Hace unos días hice una charla con preguntas abiertas del público, organizada por las comunidades Agile Sur y FullStack Sevilla. En algún momento alguien preguntó algo que me hacen mucho: cómo explicar el coste basal del software a una persona de negocio, de esas que escuchan «mantenimiento» y desconectan.
Respondí lo que suelo responder, pero mientras lo decía me salió otra cosa que no llevaba preparada, y creo que es la parte importante: el problema no es que no lo entiendan. El problema es que la metáfora con la que todos pensamos el software está rota, y ellos la usan igual que la usamos nosotros.
Heredamos la metáfora de la construcción
Decimos que construimos software. Levantamos arquitecturas, ponemos cimientos, montamos features. Todo el vocabulario viene de la construcción de edificios, y con él viene una idea de fondo que casi nunca hacemos explícita: que el grueso del coste está en la obra inicial y que el mantenimiento posterior es un porcentaje pequeño y previsible.
Bajo esa metáfora, construir más siempre es mejor. Más metros por el mismo presupuesto. Más entregado por el mismo equipo.
Con software el reparto es justo el contrario. Cada cosa que existe cuesta capacidad cada día, se toque o no. Hay que entenderla cuando alguien la lee, mantenerla compatible cuando llega lo siguiente, explicarla a quien entra nuevo en el equipo, actualizarla porque cambia el mundo alrededor aunque nadie la cambie por dentro. Y el mundo alrededor cambia mucho más rápido que hace veinte años.
A ese gasto continuo por el mero hecho de existir lo llamo coste basal, por analogía con el metabolismo basal: lo que consume un organismo solo por seguir vivo. No es deuda técnica. La deuda técnica es una decisión que tomaste y que puedes pagar. El coste basal lo pagas siempre, también con el código bueno.
Para negocio, es inventario
Cuando lo explico fuera de tecnología, lo que mejor funciona es hablar de inventario.
La imagen mental que tiene mucha gente de negocio es secuencial: hacemos una funcionalidad, la entregamos, pasamos a la siguiente. Como si lo anterior desapareciera del coste al terminarlo. Pero no desaparece: se queda en el almacén, y el almacén hay que sostenerlo. Cada cosa que dejas ahí resta un poco de la capacidad con la que vas a construir lo siguiente.
En las fases de expansión fuerte esto no se nota, y por eso engaña tanto. Si el equipo se satura, creas otro equipo. Divides, contratas, sigues creciendo y todo el mundo contento. Pero en cuanto dejas de crecer, aquello se hace bola: cada trimestre el equipo va un poco más lento, y nadie sabe señalar qué ha pasado porque no ha pasado nada en concreto. Solo se ha acumulado.
La prueba de la cirugía
La forma más rápida que conozco de enseñar que la metáfora está rota es cambiarla por otra donde el absurdo se ve solo.
Nadie va al cirujano y le pide que le abra un poco más. Nadie dice «hazme más puntos, que para eso te pago y además eres muy bueno». En cirugía todos entendemos, sin que haga falta explicarlo, que la intervención es el coste y que lo que importa es el resultado. Cuanta menos cirugía haga falta para conseguirlo, mejor cirujano.
En software hacemos justo lo contrario. Presumimos de cuánto hemos construido, medimos equipos por lo que entregan, celebramos el volumen. Enseñamos la cicatriz como si fuera el resultado.
La metáfora que sí ayuda
La que a mí me sirve es la de cultivar algo: sembrar, regar, podar, limpiar, de forma continua. Y tiene dos consecuencias que me parecen mucho más útiles que la del edificio.
La primera es que no hay que esperar señales de alarma. Si tienes un jardín y no vas nunca a cuidarlo, no necesitas un indicador que te avise: puedes dar por seguro que en unos meses estará despendolado. Es entropía, va en la naturaleza del sistema. Nuestro trabajo no es reaccionar cuando la complejidad ya duele, es gestionarla todo el rato para que no llegue ahí.
La segunda es que cambia la conversación sobre añadir. Quien sabe lo que cuesta mantener un terreno productivo durante todo el año no mete más plantas porque sí. Le pone un precio al año entero, no al día que siembra. Con software casi nunca hacemos esa cuenta: valoramos lo que cuesta construir algo, no lo que va a costar sostenerlo mientras siga vivo.
Ninguna metáfora es perfecta, y esta tampoco. El software no crece solo, y podar código es bastante más incómodo que podar un seto. Pero al menos pone el foco donde está el dinero: en lo continuo.
Qué cambia cuando cambias la metáfora
En los equipos donde este cambio ha calado, lo que he visto cambiar es esto:
- Decidir no construir algo deja de parecer una rareza defensiva y pasa a ser parte del trabajo.
- Antes de decir que sí, aparece la pregunta por el coste de sostenerlo, no solo por el de hacerlo.
- Eliminar deja de leerse como destruir valor. Quitar una funcionalidad muerta es recuperar capacidad, igual que podar.
- El trabajo de gestión de la complejidad se hace visible, y se puede defender en una priorización.
Y hay una implicación que se ha vuelto urgente. Si construir se abarata mucho, como está pasando con la IA, la parte cara no baja igual: entender, integrar, operar y sostener siguen costando lo mismo o más, porque ahora hay más cosas vivas. Abaratar la construcción sin cambiar la metáfora no resuelve el problema. Lo acelera.
La conversación completa
Todo esto salió en una charla de casi dos horas, en formato entrevista y con preguntas del público en directo. Además de las metáforas se habló de cómo explicar el coste basal a dirección, de por qué existe la tendencia a construir de más, de qué hacer cuando en tu empresa «esto es imposible», y de juniors, universidad e IA.
- Charla + AMA con Agile Sur y FullStack Sevilla (1h 44m): https://youtu.be/AZ8ReGw2Qqs
- Si prefieres algo más corto, la entrevista con Emilio Carrión (40 min) es una buena puerta de entrada: https://youtu.be/3EaUl-I74lc
- Todas las charlas y entrevistas sobre el libro: lista en YouTube
Y si quieres tirar del hilo, el libro es Menos software, más impacto, y en menos-software.eferro.net están los recursos por capítulo, gratis y abiertos.
