No hay solución mágica
En 1986, Fred Brooks publicó un ensayo que probablemente sigue siendo el texto más honesto que se ha escrito sobre por qué construir software es difícil. Se llama No Silver Bullet — “no hay bala de plata” en traducción literal, pero el sentido en español es más claro: no hay solución mágica. Cuarenta años después su argumento central no envejeció ni un poco.
Quién era Brooks
Brooks no era cualquiera. En los años 60 lideró en IBM el desarrollo de OS/360, uno de los primeros proyectos de software verdaderamente masivos de la historia. De esa experiencia, dolorosa y formativa, salió The Mythical Man-Month (1975), el libro fundacional de la gestión de proyectos de software.
Si nunca lo leíste y trabajas con software, vale la pena. De ahí viene la frase que cualquier jefatura debería tener pegada en el escritorio: “agregarle más gente a un proyecto de software atrasado lo atrasa más todavía”. Es contraintuitivo y es cierto, y explica el 80% de los desastres de TI que ves en cualquier organización.
Brooks ganó el Premio Turing en 1999 — el equivalente al Nobel en computación. Murió en 2022, dejando una de las pocas obras técnicas que envejecen bien.
Once años después de The Mythical Man-Month, Brooks escribió No Silver Bullet para responder una pregunta que en 1986 sonaba a 2026: ¿hay alguna tecnología o método que pueda multiplicar por diez la productividad del desarrollo de software en la próxima década?
Su respuesta: no.
Complejidad esencial vs complejidad accidental
El argumento se apoya en una distinción que cambia cómo se ve cualquier proyecto de software.
Complejidad accidental. La que viene del cómo: lenguajes verbosos, herramientas malas, procesos pesados, integraciones torpes. Es la complejidad que la industria sí ha logrado reducir con décadas de avances — compiladores, lenguajes de alto nivel, frameworks, IDEs, hoy también IA generativa.
Complejidad esencial. La que viene del qué: el problema mismo. Un sistema de remuneraciones municipal tiene que conocer bienios, trienios, asignaciones por antigüedad, descuentos previsionales, retenciones judiciales, casos especiales por estatuto, excepciones por dictamen de Contraloría. Eso no es código mal escrito que se pueda simplificar. Es el dominio.
Brooks dice: la mayoría de las ganancias de productividad de los últimos cuarenta años vinieron de atacar la complejidad accidental. Pero esa cantera ya está bastante exprimida. Lo que queda — la complejidad esencial — no tiene atajos. No hay solución mágica.
Por qué esto importa en software público
Cualquiera que haya implementado software en el sector público chileno reconoce el patrón. Cada vez que un proveedor llega diciendo “nuestro sistema lo simplifica todo”, lo que ocurre es predecible:
- La demo es impecable. Los flujos felices funcionan.
- Empieza la implementación real. Aparecen los casos especiales.
- “Ah, eso se configura.” Algunos sí. Otros no.
- “Eso se personaliza como un proyecto adicional.” Cotización aparte.
- Seis meses después, el sistema cubre el 80%, y el 20% que más duele se sigue haciendo en planillas o a mano.
Lo que el proveedor presentó como una solución que elimina complejidad solo redujo la accidental. La esencial — el hecho de que el Estatuto Administrativo tiene cientos de artículos, que el cálculo de bienios depende del tipo de contrato, que cincuenta años de dictámenes de Contraloría tienen valor normativo, que cada municipio tiene particularidades heredadas — sigue ahí, intacta.
Lo que Brooks sí pensaba que ayudaba
El ensayo no es derrotista. Brooks identifica cuatro cosas que sí mueven la aguja, sin ser mágicas:
Comprar antes que construir. Si alguien ya resolvió el problema, comprar es casi siempre más rápido que construir desde cero.
Refinar requerimientos con prototipos. La parte más difícil del software no es escribirlo: es decidir qué escribir. Los prototipos exponen lo que los documentos esconden.
Desarrollo incremental. Construir un sistema mínimo funcionando desde el primer mes y agregarle capacidades sobre la marcha, en vez de construir todo en silencio durante dos años y prender el switch al final.
Buenos diseñadores. Esto Brooks lo pone por encima de cualquier proceso o herramienta. La diferencia entre un sistema que funciona y uno que no, casi siempre está en quién lo diseñó. Y los buenos diseñadores no se forman con una metodología: se forman con años de exposición a problemas reales.
Cuarenta años después, todo eso sigue siendo verdad.
La pregunta que conviene hacer
Cuando un proveedor le promete a su organización que su sistema “elimina la complejidad”, la pregunta correcta no es si el producto es bueno. Es esta: ¿qué complejidad está eliminando?
Si está atacando complejidad accidental — menos clicks, mejores integraciones, interfaces más limpias, generación asistida por IA — bien. Es real, es valioso, pero es marginal.
Si pretende eliminar complejidad esencial — “el cálculo de remuneraciones es trivial con nuestro motor”, “la contabilidad municipal es estándar”, “nuestro sistema configura todo sin código” — entonces o no entendió el problema, o supone que usted no lo entendió.
No hay solución mágica. Brooks lo dijo en 1986. Nadie lo ha refutado todavía.
Lectura: No Silver Bullet — Essence and Accident in Software Engineering, Frederick P. Brooks Jr., 1986.