Programación, ¿arte o ciencia?

Antes de empezar, matizar que nada de lo que se indique se refiere a diseños de interfaces de usuario o similares. Parece lógico pensar que eso sí es un arte en la medida en que un buen (o mal) diseño visual es una excepcional vía para trasmitir emociones al usuario. La cuestión tampoco se refiere a si el producto resultado de dicha programación es arte o no. Por ejemplo, también parece claro que un juego tiene más de arte -de transmisión de emociones- que de ciencia aunque de esto último también tenga muchísimo.

La cuestión se refiere a si el hecho en sí mismo de programar es un arte o una ciencia. Si se basa más en la virtud o habilidad para hacer algo (arte) o en conocimientos obtenidos durante observación y razonamiento sistemático del que se obtienen principios generales (ciencia).

Un problema, muchas aproximaciones

Tal vez parte del problema respecto a si la programación es arte o ciencia se deba a que fijado un problema hay muchas posibles aproximaciones. Es posible hacer una cantidad infinita de variantes del mismo programa -todas ellas cumplirán el objetivo fijado- pero unas estarán basadas en algoritmos más o menos eficientes y lógicos y otras estarán basadas en vericuetos y caminos escabrosos.

El desconocimiento de técnicas de programación y algoritmos no impide por tanto realizar trabajos de programación. Ese es el primer problema dado que cuanto más cercano esté el programa a un algoritmo bien definido más fácil será su sistematización y, por tanto, más cerca estará de la ciencia.

Durante las fases de aprendizaje de un programador, desde que es novato hasta que se convierte en experto (Peter Norvig, que algo de esto sabe, fija este proceso en no menos de diez años), se producen importantes cambios en su forma de analizar y abordar un problema.

Cuando es novato tiende a utilizar todos los recursos del lenguaje de programación, sin quizá demasiado rigor científico. Demanda constantemente más información y puede empezar a trabajar sin comprender complemente el problema. A medida que va acercándose a la maestría alinea más el momento de comprender el problema en su completitud con al momento de empezar a programar. Utiliza un subconjunto de las capacidades del lenguaje de programación y sistematiza el proceso de forma continua. Es decir, tiene una metodología y en ese sentido, cabe pensar que la metodología es lo que acerca la programación a la ciencia.

Sin embargo, cuando el programador se convierte en experto se vanagloria de seguir el manual de buenas prácticas. Y el manual de buenas prácticas está bien, muy bien, pero no es una ley o principio general (que es la base de la ciencia). Es eso, un manual de buenas prácticas. A nadie se le ocurriría que un ingeniero de caminos siguiera un manual de buenas prácticas para calcular la resistencia de materiales en el diseño de un puente. Sigue leyes matemáticas no buenas prácticas y quizá por ello la imagen de la derecha tenga su punto de humor dado que, lógicamente, no es habitual ni previsible.

Las pruebas

Las pruebas, sin duda, permiten encontrar fallos en los programas, en unas ocasiones por una mala programación y en otras por un mal diseño previo. Sin embargo, las baterías de pruebas no son la solución sino la consecuencia del problema. La realización de pruebas a posteriori se puede usar para demostrar la presencia de errores en un programa, pero nunca para demostrar su ausencia (Dijkstra). Lógicamente, también los ingenieros de ramas más tradicionales hacen pruebas a posteriori para verificar si lo construido es correcto pero la gran diferencia es que sus pruebas están basadas en fundamentos matemáticos. Es decir, verifican si la construcción se ha hecho con arreglo a las leyes generales pero no dudan de tales leyes.

Sin embargo, en el caso de la programación esas leyes generales no existen salvo que desde el inicio se defina una metodología clara de las pruebas que se llevarán a cabo durante la fase de test. La existencia misma de esa metodología hará que los programadores eviten los problemas en origen.

Fuente: SecurityFocus

Esta idea se muestra de forma nítida en la programación segura. Por ejemplo, hasta 2005 Microsoft era la referencia mundial más clara de programación insegura. Sus bibliotecas de código estaban plagadas de fallos que podían ser explotados -y de hecho lo eran- en ataques de buffer overflow y otros fallos. Tanto es así, que Microsoft era asociada con la mala calidad (desde el punto de vista de seguridad) de sus productos. Algunos, como Internet Explorer, tenían fallos clamorosos y antológicos día sí y día también.

Todo fue fijar una metodología clara para los programadores e invertir en formación sobre programación segura y el número de fallos descendió de forma drástica hasta valores considerados como normales (similares a los de sus competidores). Nuevamente, parece que la existencia de una metodología (leyes) es definitiva para pasar de arte a ciencia.

Terminando

La confianza en la calidad del software es fundamental y lo será mucho más cada día que pase. Hay errores mediáticos como el del error de división en el Pentium, el efecto 2000 o Ariane 5 (lista completa de los 20 errores de software más famosos), y hay otros muchos que día a día pasan desapercibidos pero complican sobre manera la vida a los usuarios.

Etimológicamente, arte en griego se escribe τέχνη, raíz de la que también derivan palabras como tecnología o técnica. De hecho, en la Edad Media las universidades se dedicaban a enseñar las siete artes liberales, esto es, gramática, retórica, lógica, aritmética, geometría, música y astronomía. Y la programación informática depende de, al menos, tres de esas artes -hoy en día claramente ciencias-, a saber, gramática, lógica y aritmética.

Desde entonces, a lo largo de muchos siglos, se viene demostrando que actividades que hoy en día son claramente consideradas como ciencia empezaron siendo arte. Quizá un ejemplo muy claro de ello sea la medicina, que pasó de chamanes a científicos. Fue la forma sistemática y razonada de abordar los problemas lo que terminó por fijar la categoría de esas actividades como ciencia.

Tal vez, lo que nos falta es más metodología, más CMMI, más Scrum,... En definitiva, más rigor científico. O tal vez sea posible que algunos elementos de la programación sean intrínsecos de la mente humana al no poder ser modelados o automatizados y por tanto estén siempre en el ámbito del arte. Ahí dejo la cuestión.

www.tonsofit.com