La complejidad como enemigo: qué nos enseña "A Philosophy of Software Design" sobre el estado actual del desarrollo
El problema que casi todos vivimos: el software se pudre
Uno de los primeros puntos de la charla fue explicar quién es John Ousterhout y por qué su visión tiene tanto peso. Además de haber trabajado durante años en la industria, es conocido por crear el lenguaje Tcl y por sus aportes en sistemas distribuidos. Después de décadas desarrollando software, llegó a una conclusión que muchos equipos conocen demasiado bien: prácticamente todas las bases de código tienden a deteriorarse con el tiempo.
Ese fenómeno —conocido informalmente como _software rot_— fue precisamente el motivo que lo llevó a desarrollar una clase en Stanford sobre diseño de software. Según los participantes, uno de los grandes problemas de la industria es que se enseña a programar, pero rara vez se enseña realmente a diseñar sistemas.
La complejidad: el verdadero enemigo
El concepto central del libro y de toda la conversación fue la complejidad. Para Ousterhout, el mayor enemigo del software no es la velocidad, ni el lenguaje, ni siquiera la tecnología: es la complejidad innecesaria.
Durante la charla se repasaron los tres síntomas principales que plantea el autor:
- Change amplification: pequeños cambios que obligan a modificar múltiples partes del sistema.
- Carga cognitiva: la cantidad de conocimiento que necesita un desarrollador para comprender el código.
- Unknown unknowns: aquello que ni siquiera sabemos que desconocemos dentro del sistema.
Este último fue señalado como el más peligroso, porque puede provocar errores invisibles o consecuencias inesperadas incluso cuando el cambio parece correcto.
Programación táctica vs. estratégica
Otro de los conceptos más discutidos fue la diferencia entre programación táctica y estratégica.
La programación táctica busca resolver el requerimiento inmediato lo más rápido posible. Es la lógica dominante en muchos equipos modernos: cerrar tickets, cumplir features y mantener métricas de productividad.
La programación estratégica, en cambio, piensa el sistema como un todo. Busca que cada cambio no solo funcione hoy, sino que además mantenga la calidad y sostenibilidad del software en el futuro.
Los participantes coincidieron en que gran parte de la industria actual está excesivamente orientada al corto plazo, especialmente bajo dinámicas ágiles mal interpretadas donde el foco termina siendo “quemar puntos” y producir features rápidamente.
El “tornado táctico”: cuando producir mucho destruye el sistema
Uno de los términos más llamativos mencionados fue el de tactical tornado: desarrolladores extremadamente productivos en el corto plazo, celebrados por management por entregar rápido, pero que al mismo tiempo generan enormes costos ocultos de mantenimiento y deuda técnica.
El problema, señalaron, es que esos costos casi nunca los paga quien genera el problema, sino los equipos que heredan el sistema más adelante.
La crítica al dogma técnico
La charla también se volvió especialmente crítica con ciertos dogmas ampliamente difundidos en la industria: principios aplicados de forma automática, obsesión por métricas y arquitecturas excesivamente fragmentadas.
Se discutió, por ejemplo, cómo muchas organizaciones adoptan reglas rígidas sobre:
- cantidad máxima de líneas por función,
- complejidad ciclomática,
- cobertura de tests,
- separación extrema de clases y servicios,
sin cuestionar realmente si esas decisiones ayudan o empeoran el sistema.
Uno de los participantes citó incluso la famosa frase de Martin Fowler sobre sistemas distribuidos: “la regla número uno de los objetos distribuidos es no distribuirlos”. La idea detrás de esa provocación es simple: muchas veces se introduce complejidad arquitectónica innecesaria en nombre de buenas prácticas adoptadas como religión.
La inteligencia artificial y el nuevo caos del código
Aunque la charla no estaba centrada en IA, inevitablemente apareció el tema. Y el consenso fue contundente: la inteligencia artificial generativa puede convertirse en un acelerador masivo de programación táctica.
Uno de los participantes definió a la IA como “un huracán categoría 5” de generación de deuda técnica: capaz de producir código funcional extremadamente rápido, pero potencialmente desastroso para la sostenibilidad de una base de código si no existe pensamiento estratégico detrás.
El problema no es que la IA escriba código. El problema es quién toma las decisiones de diseño.
¿La industria del software sigue siendo inmadura?
La conversación cerró con una reflexión interesante: quizás la razón por la cual aparecen nuevos frameworks, paradigmas y “verdades absolutas” cada pocos años es porque la ingeniería de software todavía no alcanzó la madurez de otras disciplinas como la ingeniería civil.
A diferencia de otras ingenierías, donde los principios fundamentales permanecen relativamente estables durante décadas, el software vive en una reinvención constante. Y eso genera una industria donde muchas veces las modas reemplazan a la reflexión profunda.
Tal vez por eso el libro de Ousterhout resulta tan vigente: porque recuerda algo simple, pero fácil de olvidar. Que escribir software no es solamente hacer que algo funcione, sino diseñar sistemas que puedan sobrevivir al tiempo, al crecimiento y a las decisiones futuras.
