Programación, ¿arte o ciencia?



RSS

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

RSS

4 comentarios

  1. Manu, hace muchos años me enseñaron la diferencia entre un programador de C bueno, uno malo y otro excelente.
    Tal y como dices arriba, el malo utiliza todas las opciones que le da el lenguaje. Se hincha a utilizar punteros para todo reservando y eliminando zonas de memoria constantemente en lugar de utilizar memoria estática más fácil de gestionar. Sus programas suelen ser un colección de traps uno detrás de otro.
    El bueno utiliza unas pocas herramientas del lenguaje, sabe crear funciones cuando hay procesos repetitivos, optimiza el código -y su esfuerzo- y no usa memoria dinámica ni punteros porque ha aprendido que son muy complejos de mantener en el futuro (ya le ha tocado mantener código de otros varias veces).
    El excelente es igual que el bueno pero ha llegado a un nivel de elegancia en la programación que hace que incluso la gestión de la memoria dinámica parezca fácil.

    Para mi el primero (el malo) es un chapucillas. El segundo (el bueno) está muy cerca de la ciencia y el tercero (el excelente) es un artista con nivel de genio.

    Y comparto contigo que la metodología sirve para acelerar el paso del primer tipo al segundo. Al tercero se llega con dotes personales y mucho esfuerzo.

    ResponderEliminar
  2. Yo añadiría otra pregunta al título del artículo:
    Programación ¿arte o ciencia? - ¿O pragmatismo-prisas?
    Teniendo en cuenta las prisas en las que nos movemos para solucionar un problema o desarrollar lo pedido, se tira mucho de salidas rápidas y no siempre son las más convenientes. Me explico:
    Reinstalar un pc sin tener tiempo a averiguar cuál ha sido el problema que ha causado el error, diseñar un programa de limpieza del registro de windows para vista y superiores con API´s de win32 y no con las de win NT nativo ya que sale a un precio astronómico fuera del alcance de un bolsillo normal. Estos programas con API´s win 32 provocan una desorganización de las claves del registro de windows que para solucionarlo obliga a formatear y reinstalar desde cero el equipo para recuperar el rendimiento pleno del mismo.
    Estos dos ejemplos los pongo para intentar explicar que en el mundo que nos toca vivir, prevalece la inmediatez a buscar el problema en si para solucionarlo. Y opino que le afecta de lleno a la programación, puesto que creo que se siguen esas mismas pautas.
    "¿Para cuándo lo quiere, para dentro de un rato? - No, para ayer."
    Yo digo, "Bueno, lo imposible se lo hacemos al momento. Para los milagros, tendrá que esperar un poco."
    Un saludo.

    ResponderEliminar
  3. Metodología, metodología, metodología. He ahí el quid de la cuestión. Casualmente llevo un par de semanas en colaboración con una empresa suiza en proceso de certificación de CMMI5 (alucinas) y aplicando metodologías SCRUM (son todos SCRUM MASTER) desde hace 3 años. Curiosamente su ratio de finalización de proyectos tanto en tiempo como en margen objetivo está cercano al 90%, y la percepción del cliente en cuanto a la calidad del software generado es de un 8 en una escala de 0-10. Está claro que la metodología es un medio necesario para la consecución del fin, pero también tengo que decir que no suficiente.
    Hay que incluir en la fórmula la variable cultural e histórica. Vuelvo al ejemplo de la empresa con la que llevo tiempo colaborando. Viendo los equipos de trabajo, se trata de personal mucho mas "cuadriculado" que nosotros, con un concepto estricto de la calidad, la responsabilidad sobre su trabajo y del cumplimiento de los procedimientos definidos.

    Con esto no estoy culpando a los programadores de la falta de calidad de algunos desarrollos. Probablemente el primer problema lo tengan (tengamos) los Directores de Calidad/Operaciones y los Gerentes por no potenciar la implantación de políticas concretas metodológicas y de calidad, así como por vender proyectos inalcanzables tanto en plazos como en niveles de calidad esperados respectivamente (y como decía Alberto, luego el programador tiene que hacer lo imposible al momento y milagros en un rato, aunque todos sabemos que al final se hacen apaños más que otra cosa).

    Lo que tengo claro, y en ello estamos, es que para facilitar el cambio lo primero es la metodología y posteriormente la gestión del cambio. Probablemente en el camino se tengan que quedar muchos profesionales dedicados exclusivamente al arte, pero el resultado seguro que merece la pena. El reto es realmente apasionante.

    ResponderEliminar
  4. Interesantes comentarios. Pero yo le daría la vuelta al Anónimo. Denominaría "Artista" al que, sin tener conocimiento alguno, consigue el fin u objetivo que debía satisfacer el programa, sin importar la eficiencia, que rara vez será la óptima. El que lo hace de la forma más eficaz aplicando lo más adecuado para cada situación, sería el experto y, en mi opinión, el que más se aproxima a lo que denominaríamos científico.

    ResponderEliminar


Los contenidos de Tons of IT están sujetos a licencia Creative Commons Reconocimiento 3.0 salvo donde se indique lo contrario.