Hola, estimados devs. No, no estoy hablando de la inteligencia artificial ni de las crisis tecnológicas actuales. Me refiero a una crisis mucho más antigua, ocurrida a finales de los años sesenta, que terminó dando origen a una nueva disciplina: la Ingeniería de Software. Y, como suele suceder en la historia de la tecnología, aquella “crisis” no fue simplemente un fracaso, sino una oportunidad que obligó a la industria a madurar. Entenderla es especialmente relevante hoy, en el que existen muchos miedos por la irrupción de la inteligencia artificial. Hoy la historia nos dará una lección de valentía y optimismo, ya verás.

A finales de la década de 1960, la industria tecnológica enfrentó un problema inesperado. El hardware avanzaba con rapidez: más potencia, más memoria, más aplicaciones posibles. Sin embargo, el software que se suponía que debía aprovechar ese hardware no evolucionaba con la misma disciplina. Los proyectos crecían en tamaño y complejidad, pero las prácticas de desarrollo seguían siendo improvisadas.

Ese período es conocido como la “crisis del software”, un término que se popularizó en la histórica conferencia de la OTAN llamada NATO Software Engineering Conference. En esa conferencia, celebrada en Alemania en 1968, se utilizó deliberadamente la expresión software engineering con una intención clara: el desarrollo de software debía convertirse en una disciplina de ingeniería, no seguir siendo una actividad artesanal.

El problema no era programar, era escalar

En los años 50 y comienzos de los 60, los programas eran relativamente pequeños y solían ser escritos por una o pocas personas. Pero a medida que el software comenzó a utilizarse en defensa, banca, telecomunicaciones y sistemas científicos, los proyectos crecieron a una escala que no tenía precedentes.

Los síntomas eran recurrentes: proyectos que excedían ampliamente el presupuesto, cronogramas que se duplicaban o triplicaban, sistemas que nunca se completaban y, sobre todo, software extremadamente difícil de mantener. Una modificación menor podía introducir errores inesperados en otras partes del sistema. El conocimiento quedaba encapsulado en la mente de ciertos programadores, lo que hacía que el mantenimiento fuera una pesadilla por lo riesgoso y costoso.

El problema central era la complejidad no controlada.

Código espagueti y ausencia de estructura

En aquella época era común el uso indiscriminado de la tan temida instrucción goto, lo que generaba programas con flujos de ejecución difíciles de seguir. El código se convertía en lo que luego se denominaría código spaghetti, expresión muy usada hasta el día de hoy. No existían principios formales ampliamente aceptados sobre cómo dividir un sistema en partes comprensibles y modificables.

En 1968, el científico de la computación Edsger W. Dijkstra, un crack, publicó su influyente artículo Go To Statement Considered Harmful, argumentando que el uso de goto impedía el razonamiento formal sobre los programas. Su propuesta impulsó el movimiento de la programación estructurada, que promovía el uso de estructuras de control claras como secuencia, selección e iteración.

Sin embargo, aunque la programación estructurada mejoraba el interior de los programas, aún quedaba pendiente una pregunta mayor: ¿cómo diseñar sistemas completos que pudieran evolucionar sin volverse inmanejables?

El nacimiento del diseño modular

En 1974 se publicó un gran libro, uno de los fundamentales, llamado Structured Design de Larry Constantine y Glenford Myers, que formalizó principios que hoy consideramos fundamentales: cohesión y acoplamiento. Allí se sistematizó la idea de que un buen sistema debe dividirse en módulos con responsabilidades claras (alta cohesión) y con dependencias mínimas entre ellos (bajo acoplamiento).

La cohesión y el acoplamiento nacieron formalmente aquí y son importantísimos a día de hoy, ¿verdad? Hoy es un estándar.

Este enfoque trasladó la disciplina desde el nivel del flujo de control hacia el nivel de la arquitectura del sistema. Ya no se trataba solo de escribir código correcto, sino de estructurar sistemas que pudieran mantenerse, ampliarse y comprenderse con el tiempo.

A partir de ese momento, la ingeniería de software comenzó a consolidarse como un campo propio, con modelos de ciclo de vida, técnicas de análisis de requisitos, pruebas sistemáticas y métodos de gestión de proyectos. Una ingeniería en todo el sentido de la palabra.

¿Fue realmente una crisis?

Históricamente, algunos académicos sostienen que la palabra “crisis” fue en parte retórica. Toda disciplina joven atraviesa un período de crecimiento desordenado antes de madurar. Sin embargo, en términos industriales, los fracasos eran lo suficientemente frecuentes y costosos como para justificar la alarma.

Lo importante no es tanto si fue una crisis en sentido dramático, sino que marcó un punto de inflexión. La comunidad técnica reconoció que el software no podía crecer indefinidamente sin principios estructurales sólidos.

El legado en la actualidad

Muchos conceptos modernos son herederos directos de ese período. La orientación a objetos, los principios SOLID, la arquitectura limpia, los microservicios e incluso los modelos de calidad como ISO/IEC 25010 tienen en su base la misma preocupación central: controlar la complejidad.

Aquí te hablo más de calidad de software e ISO 25010

Cuando hoy hablamos de mantenibilidad, modularidad o separación de responsabilidades, estamos aplicando lecciones aprendidas hace más de medio siglo. La diferencia es que ahora contamos con herramientas, lenguajes y marcos conceptuales mucho más desarrollados.

La crisis del software no fue el fracaso del software, fue el momento en que la disciplina entendió que debía profesionalizarse. Fue el punto en que programar dejó de ser solo escribir instrucciones para una máquina y comenzó a ser diseñar sistemas que deben sobrevivir al tiempo.

En última instancia, la lección sigue vigente: la complejidad no desaparece, solo puede gestionarse. Y la ingeniería de software nació precisamente para eso.

Hoy muchos desarrolladores observan con inquietud el avance acelerado de la inteligencia artificial y se preguntan si estamos ante una nueva “crisis”. La historia sugiere algo distinto. Cada gran transformación tecnológica ha generado incertidumbre antes de generar progreso. Lo que en los años sesenta parecía el colapso del software terminó dando origen a una disciplina más madura, más estructurada y más sólida. Tal vez la verdadera pregunta no sea si la inteligencia artificial reemplazará a los desarrolladores, sino cómo nosotros, como profesionales, vamos a evolucionar junto con ella. Si algo nos enseñó la primera crisis del software es que las crisis no necesariamente marcan el fin de una era, muchas veces son el punto de partida de la siguiente.

Sea como sea, el que mejor se adapte a lo que sea que venga le irá mejor, y más si sabes estos temas y los compartes con tu equipo de ingeniería, vamos, que te convertirás en técnico y culto, poderosa combinación. Be water, my friend.

Si esta entrada te ha gustado, ¡compártela, crack! 🎉

Créditos de imagen de portada: Foto de Ed Wingate en Unsplash