⏱️ Lectura: 12 min
Un ingeniero que firma como Graybeard publicó el 10 de septiembre de 2026 un ensayo con una tesis incómoda: el software no vuelve locas a las personas por ser difícil, sino por lo barato que parece cambiarlo. Su argumento central tiene nombre propio, el costo oculto del software: la distancia entre lo que cuesta pedir un cambio y lo que realmente cuesta sostenerlo.
📑 En este artículo
La comparación que usa es física: mover una pared a mitad de obra tiene un costo visible, hay escombros y cañerías rotas. Mover una función en el código parece gratis porque no deja polvo, aunque el costo real se acumula después, en reuniones, migraciones y paneles de métricas rotos.
TL;DR
- El ensayo Software Drives People Insane lo publicó Graybeard el 10 de septiembre de 2026 en graybeard.ing.
- La tesis: el software mezcla velocidad, dinero, complejidad y libertad de cambiar de idea, algo que otras industrias no tienen.
- El autor describe la mayoría del software como una planilla de cálculo glorificada: formularios, permisos, cálculos y colas.
- A diferencia de mover una pared en una obra, cambiar código no deja escombros visibles, así que su costo real queda oculto.
- El ciclo ‘se puede, se debería, por qué no está listo’ retroalimenta la sensación de urgencia permanente en los equipos.
- El ensayo no da una solución cerrada, pero sugiere fabricar fricción artificial, como un definition of done explícito.
- La deuda técnica y el scope creep son los efectos medibles de un mecanismo que, según el autor, es también psicológico.
Qué pasó
Graybeard, un desarrollador que escribe bajo seudónimo en su blog personal, publicó el ensayo Software Drives People Insane el 10 de septiembre de 2026. Su punto de partida es una observación simple: ha visto a suficiente gente normal volverse, en sus palabras, ‘villanos de Bond de segunda categoría’ durante el desarrollo de un producto, como para descartar que sea solo un problema de personalidad.
La pregunta que se hace no es técnica sino organizacional: ¿qué tiene el software, como actividad, que produce ese efecto de manera tan consistente? Su respuesta combina cinco ingredientes que, por separado, son manejables: velocidad de iteración, dinero disponible, complejidad técnica, capas de abstracción y la libertad casi ilimitada de cambiar de idea a mitad de camino. Juntos, según el autor, generan efectos secundarios extraños.
El ensayo insiste en que, quitando el branding y los diagramas de arquitectura, la mayoría del software es aburrido: un formulario acá, un endpoint de API allá, permisos, cálculos, algún flujo de trabajo y una base de datos. En sus palabras, ‘la mayoría del software sigue siendo una planilla de cálculo glorificada’. El contraste que le interesa es justamente ese: cómo algo tan mundano en su forma final puede volver tan tenso el proceso de construirlo.
Contexto e historia
La analogía que sostiene el ensayo viene de la construcción. Si alguien decide, a mitad de la obra, que la cocina debe ir del otro lado del edificio, todos entienden que esa decisión tiene un costo: ya se cortaron tablas, ya se tendió la cañería, hay que romper algo que estaba terminado. El costo es físico, así que nadie puede fingir que no existe.
Mover la cocina en software puede parecer un ‘arreglo simple’. El trabajo sigue siendo costoso, pero el gasto se acumula en silencio. Entre el cambio de contexto, el riesgo de regresión y el desgaste de la arquitectura aparecen impulso perdido, supuestos olvidados y reuniones interminables para ‘alinearse’. Como no hay polvo ni escombros visibles, es fácil creer que el cambio salió gratis.
El problema se agrava porque cambiar software a veces sí es barato. Un ajuste puede tomar realmente una hora, mientras que otro pedido de apariencia idéntica puede propagarse por todo el sistema y romper cosas en producción. Esa opacidad crea un hábito peligroso: cualquier ‘idea genial’ que suene ‘rapidísima’ entra al roadmap, casi siempre con urgencia.
Ese hábito es el motor del ciclo que describe el ensayo: alguien tiene una idea en una reunión y casi no hay resistencia entre la idea y la realidad. ¿Se puede cambiar cómo funciona esta pantalla? ¿Se puede cambiar el modelo de negocio, perseguir otro segmento de clientes, sumar un flujo nuevo, construir un sistema de eventos propio? La respuesta casi siempre es alguna variante de ‘sí, se puede’. Con el tiempo, ‘se puede’ pasa a ‘se debería’, y ‘se debería’ pasa a ‘¿por qué no está listo todavía?’.
flowchart TD
A["Alguien tiene una idea en una reunion"] --> B["Se puede hacer"]
B --> C["Se deberia hacer"]
C --> D["Por que no esta listo todavia"]
D --> E["Entra al roadmap con urgencia"]
E --> AEl diagrama resume el mecanismo: sin un punto de fricción real, el ciclo se retroalimenta y cada iteración suma una idea nueva sin cerrar la anterior.
Detalles técnicos: dónde se esconde el costo oculto del software
El costo oculto del software no es abstracto, se puede ver en un diff. Un pedido que suena a ‘una tarde de trabajo’ en una reunión de producto casi nunca se queda en una línea de código cuando llega al repositorio.
// Antes: cancelar una suscripcion es una operacion directa
function cancelSubscription(userId) {
db.subscriptions.update(userId, { status: "cancelled" });
}El pedido original en la reunión fue: ‘agreguemos una encuesta corta antes de cancelar, para entender por qué se van’. Suena a un formulario y un guardado. Así termina, en la práctica, dos sprints después:
// Despues: la misma funcion, con el costo real ya visible
function cancelSubscription(userId, surveyResponse) {
logSurveyResponse(userId, surveyResponse); // tabla nueva, permiso nuevo
applyRetentionOffer(userId); // toca el servicio de billing
db.subscriptions.update(userId, { status: "cancelled" });
notifyRetentionTeam(userId); // cola nueva, consumer nuevo
emitAnalyticsEvent("subscription_cancelled_v2"); // rompe los dashboards que leian v1
}Nada de esto es un error de estimación. Cada línea nueva es una decisión razonable tomada por una persona distinta, en un momento distinto, sin ver el conjunto. El scope creep (la expansión progresiva del alcance de un proyecto) rara vez llega como un pedido grande: llega como una sucesión de pedidos chicos, cada uno defendible por separado.
⚠️ Ojo: que un cambio sea barato de programar no significa que sea barato de operar. La deuda que genera un ‘sí, se puede’ se paga en incidentes, no en el sprint donde se aprobó.
Cómo aplicarlo en tu equipo
El ensayo no ofrece una receta cerrada, pero su diagnóstico sí sugiere una salida: si el software no tiene fricción física, hay que fabricar fricción artificial en el proceso, antes de que un pedido llegue al código. Eso no significa burocracia extra por burocracia, significa hacer visible el costo que hoy está escondido.
La herramienta más simple es una definition of done explícita, revisada antes de estimar y no después. No alcanza con ‘está hecho cuando compila’: tiene que nombrar los sistemas downstream que el cambio toca.
# definition-of-done.yaml
feature: "encuesta de cancelacion"
listo_cuando:
- tests: "cubre el flujo nuevo y el flujo viejo"
- rollback: "existe un flag para apagarlo sin deploy"
- metricas: "los dashboards de retencion se actualizaron, no solo el evento nuevo"
- alcance: "el equipo de billing aprobo el cambio en applyRetentionOffer"
- estimacion: "el ticket describe el costo real, no solo el pedido original"Este archivo no resuelve el problema por sí solo, pero cumple la misma función que los escombros en una obra: obliga a nombrar, antes de empezar, qué se va a romper. Cuando nadie puede llenar una fila del checklist, esa es la señal de que el pedido ‘rápido’ no lo es.
Impacto y análisis
La utilidad del ensayo, más allá de la anécdota, está en dar vocabulario a un problema que la mayoría de los equipos de ingeniería reconoce pero rara vez nombra. La tabla siguiente compara tres tipos de cambio típicos y dónde se esconde, en cada uno, el costo que no aparece en la estimación inicial.
| Tipo de cambio | Costo visible al pedirlo | Dónde se esconde el costo real | Cómo mitigarlo |
|---|---|---|---|
| Agregar un campo a un formulario | Ninguno, ‘es un campo’ | Migraciones, validaciones y reportes que ya asumían el esquema viejo | Definition of done que incluya migraciones y dashboards |
| Cambiar el flujo de cancelación | Una tarde de trabajo | Servicio de billing, colas de eventos, dashboards de retención | Revisar dependencias antes de estimar, no después |
| Cambiar el modelo de negocio | ‘Solo hay que cambiar el mensaje’ | Arquitectura entera diseñada para el modelo anterior | Congelar cambios estructurales por sprint y medir el costo de revertir |
Esta lógica conecta con un concepto conocido en ingeniería de software: la deuda técnica, entendida como el costo futuro que se acepta a cambio de una solución rápida hoy. Lo que aporta el ensayo de Graybeard es el mecanismo psicológico detrás de por qué los equipos siguen acumulando esa deuda incluso cuando la conocen: no hay un momento natural en el que alguien diga ‘esto ya está terminado’, porque siempre hay una palanca más al alcance de la mano.
Esa ausencia de un punto final es, para el autor, la raíz de la neurosis organizacional. Un carpintero deja el martillo porque el mueble ya existe. En software, el botón siempre podría ser mejor, la consulta siempre podría ser más rápida, las abstracciones siempre podrían ser más limpias. El producto siempre podría expandirse a un mercado adyacente. Si uno quiere, siempre hay otra palanca al alcance.
💭 Clave: el ensayo no dice que cambiar de dirección esté mal. Dice que la misma decisión se nombra distinto según quién la toma: un fundador que cambia de rumbo cada semana ‘responde al mercado’, un ingeniero que agrega infraestructura nueva ‘piensa en escala’. El lenguaje disfraza el mismo problema.
Qué sigue
El ensayo de Graybeard no propone una solución institucional, y ahí está su límite: describe el mecanismo con precisión, pero deja a cada equipo la tarea de fabricar su propia fricción. Lo más probable es que su vocabulario, el costo oculto del software, el ciclo de ‘podríamos a deberíamos’, circule en retrospectivas y publicaciones de ingeniería como una forma cómoda de nombrar algo que antes solo se sentía.
Para un equipo concreto, el siguiente paso no es filosófico: es auditar los últimos cinco pedidos ‘rápidos’ que terminaron tomando semanas y ver qué tenían en común. Casi siempre la respuesta es la misma que señala el ensayo: nadie preguntó, antes de aceptar el pedido, qué sistemas downstream asumían el comportamiento anterior.
📖 Resumen en Telegram: Ver resumen
Probalo vos: la próxima vez que alguien pida un cambio ‘de una línea’, pedile que llene la fila de ‘alcance’ del checklist antes de estimarlo, y compará cuánto tarda en responder.
Preguntas frecuentes
¿Qué es el costo oculto del software?
Es la diferencia entre lo que parece costar pedir un cambio y lo que realmente cuesta sostenerlo en producción: migraciones, dashboards, servicios downstream y el tiempo de coordinación que no aparece en la estimación inicial.
¿Quién es Graybeard?
Es el seudónimo de un desarrollador que escribe en el blog graybeard.ing sobre cultura de ingeniería y organizaciones de software. El ensayo analizado se publicó el 10 de septiembre de 2026.
¿Qué es el scope creep y cómo se relaciona con este fenómeno?
El scope creep es la expansión progresiva y no planificada del alcance de un proyecto. El ensayo describe el mecanismo psicológico que lo produce: cada pedido chico es defendible por separado, aunque la suma sea inmanejable.
¿Cómo distinguir un cambio realmente rápido de uno que solo lo parece?
Preguntando, antes de estimar, qué sistemas downstream asumen el comportamiento actual. Si nadie en la sala puede responder en segundos, el cambio no es tan rápido como suena.
¿Esto aplica solo a startups o también a empresas grandes?
Aplica a cualquier organización donde la distancia entre una idea y su implementación sea corta, lo cual describe tanto a una startup de tres personas como a un equipo grande con demasiada autonomía técnica.
¿Qué relación tiene esto con la deuda técnica?
La deuda técnica es el costo futuro aceptado a cambio de una solución rápida hoy. El ensayo explica por qué los equipos la siguen acumulando incluso cuando la conocen: no existe un punto natural de ‘terminado’ en software.
Referencias
- Software Drives People Insane, Graybeard: el ensayo original que plantea la tesis del costo oculto del software.
- Scope creep, Wikipedia: definición y ejemplos de la expansión no planificada de alcance en proyectos.
- Technical debt, Wikipedia: el concepto de deuda técnica y su origen en la ingeniería de software.
- Scrum (software development), Wikipedia: contexto sobre la práctica de ‘definition of done’ citada en la nota.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios