Edsger Dijkstra: por qué la disciplina vence a la viveza

7 min de lectura

Para él, la chapucería era un fallo de diseño

La ofensa no eran los bugs, sino la despreocupación

A Edsger W. Dijkstra se le recuerda a menudo por un algoritmo, una carta famosa sobre goto y una reputación de no tolerar el pensamiento descuidado. La reputación era merecida.

Nacido en Rotterdam en 1930, en 1952 se convirtió en el primer programador oficial de los Países Bajos en el Mathematisch Centrum de Amsterdam. Más tarde trabajó en Eindhoven, en Burroughs y en la University of Texas at Austin. En el camino nos dejó el algoritmo del camino más corto, aportes decisivos sobre semáforos y sistemas operativos, y un conjunto de ensayos lo bastante afilado como para poner a medio oficio a la defensiva.

Tenía poca paciencia con la costumbre, todavía muy común en software, de celebrar cualquier cosa que sobreviva a la demo y dejar las preguntas difíciles para cuando producción empiece a gritar. Para Dijkstra, el problema central no era que los programas a veces tuvieran bugs. El problema más hondo era que los desarrolladores aceptaran la confusión como un estado normal.

Por eso sus textos siguen pegando tan fuerte. No escribía como un vendedor de frameworks ni como un consultor de procesos. Escribía como alguien que había visto lo que pasa cuando la complejidad crece más rápido que la comprensión. Y después se negó a halagar a quienes la provocaban.

La programación estructurada fue una rebelión contra el caos

En los años sesenta, los programas grandes se estaban convirtiendo en masas enredadas de saltos, banderas, estado oculto y flujos de control que solo sus autores originales podían seguir. La máquina los ejecutaba. Los humanos los sufrían.

La carta de Dijkstra de 1968, “Go To Statement Considered Harmful”, se volvió el símbolo público de un movimiento más amplio, aunque el argumento de fondo ya está en su ensayo anterior A Case against the GO TO Statement. El eslogan se simplificó enseguida hasta convertirse en una pelea sintáctica, como suele pasar. El argumento real era más serio. Si el flujo de control puede saltar a cualquier parte, razonar sobre un programa se vuelve mucho más difícil de lo necesario. Y cuando razonar se vuelve difícil, la calidad se convierte en teatro.

La programación estructurada no trataba de pureza por la pureza misma. Trataba de crear código cuyo comportamiento pudiera entenderse localmente, componerse con seguridad y comprobarse con disciplina. Secuencia, selección, iteración, límites claros, invariantes explícitas. No porque eso se vea ordenado, sino porque reduce el espacio en el que el software puede mentirte.

El mismo argumento aparece hoy cuando un equipo intenta domar una base de código crecida sin control. Sustituye el efecto fantasma a distancia por responsabilidad explícita. Elimina el acoplamiento oculto. Reduce las funciones hasta que digan una sola cosa con claridad. Deja de felicitar a la persona que “simplemente sabe” cómo funciona el desastre.

La corrección empieza antes de ejecutar la prueba

La frase de Dijkstra sobre las pruebas se cita sin parar y casi siempre se entiende de forma superficial. No estaba despreciando las pruebas. Estaba advirtiendo contra el pensamiento mágico.

Una suite de pruebas es evidencia. Buena evidencia, a veces excelente. No es absolución. Si el diseño subyacente es incoherente, si las responsabilidades están embarradas entre capas, si las reglas del negocio se duplican en seis lugares con palabras apenas distintas, entonces una pared de checks verdes quizá solo demuestre que la confusión todavía no alcanzó los casos límite que sí mediste.

Esa idea encaja dolorosamente bien con el software moderno. Muchos equipos hablan de calidad mientras dejan el sistema estructuralmente incapaz de ser razonado con calma. Acumulan pruebas end-to-end, pasos de aprobación y rituales de pull request porque no confían en la forma del código. Los rituales están compensando deuda de diseño.

Dijkstra empujaba la responsabilidad hacia antes. Pensar antes de codificar. Declarar supuestos. Hacer legible el flujo de control. Mantener el modelo mental lo bastante pequeño como para que la corrección se pueda discutir en vez de venerarse.

Su algoritmo lo hizo famoso. Su estándar era más alto.

Sí, Dijkstra nos dio el algoritmo de camino más corto que tarde o temprano encuentra cualquier estudiante de informática. Sí, trabajó en semáforos, exclusión mutua, prevención de interbloqueos, sistemas autoestabilizantes e ideas fundamentales para lenguajes de programación y computación distribuida. El currículum es absurdo.

Pero el desarrollo de software no necesitaba sobre todo otro genio capaz de resolver un problema matemático difícil. Necesitaba a alguien dispuesto a insistir en que la programación cotidiana dejara de ser un pantano de excepciones ingeniosas y salidas improvisadas.

Por eso insistía tanto en la elegancia, la simplicidad y la disciplina. No como lujos estéticos. Como necesidades operativas. Los sistemas complejos ya contienen suficiente dificultad inevitable. Añadir encima confusión evitable es negligencia profesional con mejor marketing.

El culto al desarrollador héroe le habría molestado

Una gran parte del folclore moderno del software sigue girando alrededor del desarrollador héroe. La persona que recuerda el interruptor oculto. La persona que puede parchear producción a las dos de la mañana. La persona que por sí sola entiende el motor de facturación, la pipeline de despliegue o la integración maldita que nadie se atreve a tocar.

Dijkstra habría visto ahí un fallo de liderazgo y de diseño, no grandeza.

El software no debería depender de la mística. No debería requerir una iniciación ritual. Si entender el sistema depende de memoria tribal y prestigio frágil, la organización construyó un juego de estatus alrededor de la opacidad.

Por eso su trabajo importa mucho más allá de los debates de sintaxis. Estaba defendiendo una cultura profesional en la que los desarrolladores reducen la complejidad accidental en lugar de convertirla en palanca personal. La recompensa no es solo calidad técnica. Es cordura organizativa.

Lo que Dijkstra todavía nos enseña

El mensaje de Dijkstra sobrevive porque el software sigue recreando las condiciones que lo enfurecían.

Seguimos glorificando la viveza cuando la claridad serviría mejor.

Seguimos dejando que la arquitectura se desparrame hasta que los equipos necesiten ceremonias para coordinarse alrededor de una confusión evitable.

Seguimos confundiendo las pruebas a posteriori con diseño disciplinado.

Seguimos premiando más al guardián del laberinto que a la persona que quita una pared.

La lección duradera no es que cada programa deba verse matemáticamente impecable. Los sistemas reales son más desordenados que los manifiestos. La lección es que el software mejora cuando tratamos la comprensibilidad como una restricción dura. La claridad no es decoración. Es una condición previa para la corrección, la colaboración y la velocidad sostenida.

Dijkstra no les pidió a los desarrolladores menos ambición. Les pidió que dejaran de impresionarse por las cosas equivocadas.

Referencias

A Dijkstra no le entusiasmaban mucho las bibliografías. Esta es para el resto de nosotros.

• Edsger W. Dijkstra Archive, University of Texas at Austin
• A Case against the GO TO Statement (EWD215)
• On the reliability of programs (EWD303)
• Cita del ACM Turing Award para Edsger W. Dijkstra
• Resumen biográfico: Edsger W. Dijkstra en MacTutor