¿Se puede programar sin programadores?

El modelo clásico de desarrollo de software implica los siguientes actores:

• El analista que realiza el análisis de requerimientos del programa.
• El diseñador que realiza el diseño de alto nivel del programa.
• El programador que toma este diseño de alto nivel y lo convierte en código fuente de un lenguaje de programación.

Lo importante aquí es que ese diseño de alto nivel no es completo en absoluto y por su propia naturaleza está lleno de ambigüedades. Estas ambigüedades deben ser resueltas por el programador al convertirlo en código fuente de un lenguaje de programación. Es clave entender que no existe, ni puede existir, un sistema automático para resolver estas ambigüedades. El diseñador puede escribir en su diseño conceptual, por ejemplo: “Módulo que crea la salida del Cuadernillo 60 para la administración pública” y es responsabilidad del programador saber qué datos debe convertir, obtener la especificación técnica del cuadernillo 60 y crear ese módulo.

Una vez visto este modelo de desarrollo: ¿Cómo pasamos a un modelo en el que se elimina al programador y se produce código automáticamente? La respuesta es sencilla: “Haciendo que el diseñador resuelva todas las ambigüedades en su diseño conceptual”. Efectivamente se seguirá programando, se seguirán resolviendo las ambigüedades que es el verdadero trabajo del programador, con la salvedad de que esa programación se hará diagramando en UML en lugar de escribiendo en un lenguaje de programación.

Existen muchos sistemas que permiten esta generación de código a partir de UML entre los cuales yo recuerdo el software de modelado de IBM-Rational y el Together Soft. De hecho la nueva versión de UML en preparación aumenta sobre todo la capacidad de concreción de los modelos UML, para que puedan ser utilizados como lenguaje de programación. Estos sistemas tienen un valor como ayuda al programador, pero desde luego no elimina la necesidad del mismo (a menos, por supuesto, que todo el trabajo “real” del programador lo haga el diseñador, en cuyo caso lo que en realidad conseguiremos es aumentar el coste del proyecto ya que el diseñador cobra sueldos mayores que el programador).

Sobre esto, sobre los programas que prometen “revolucionar” la industria del software, y que aparecen cada pocos años para ser rápidamente olvidados nada mejor que leer el artículo clásico de 1987 “No Silver Bullet”. Su planteamiento es el siguiente: La programación se compone de dos partes, las partes “intrínsecas” al trabajo de programación (pensar en el problema, resolver las ambigüedades, entender los estándares, “pensar” al fin y al cabo) y las partes que podríamos considerar “accidentales” (expresar la idea en el lenguaje de programación, el propio acto de teclear, etc). Cualquier sistema que aparezca solo puede tratar de acortar las partes “accidentales”. Alguien puede crear un lenguaje de programación más fácil para exponer mis ideas (o que me permita expresarlas con dibujos, como el UML), un reconocedor de voz que me evite escribir en el teclado. Pero puesto que la mayor cantidad de tiempo se va en las partes “intrínsecas” de la programación, no en las “accidentales”, estas herramientas lo máximo que consiguen es un incremento marginal de la productividad.

Existen sistemas con los que sí se pueden llegar en un futuro a revolucionar el desarrollo de software. Son sistemas que intentan atacar esas partes “intrínsecas”, intentan evitar que sea un programador (o diseñador, o quien sea) el que tenga que especificar el algoritmo concreto que el ordenador debe seguir. Son sistemas experimentales como la programación genética o sistemas conocidos desde hace años como la programación lógica, la programación funcional, los sistemas de aprendizaje por reglas o las redes neuronales. Algunos de estos sistemas han tenido y tienen muy buenos resultados en áreas concretas aunque hasta ahora no se ha sabido exportar su éxito al software en general.