Programming as theory building (2)

Este post es una continuación del anterior que trataba sobre el artículo Programming As Theory Building de Peter Naur. Había quedado pendiente el planteo de las consecuencias de ver a la programación como una construcción de teorías. Las que extraje del artículo son: Modificar un programa no es modificar un archivo de texto.

In a program modification an existing programmed solution has to be changed so as to cater for a change in the real world activity it has to match. What is needed in a modification, first of all, is a confrontation of the existing solution with the demands called for the desired modification.

Esto significa que para poder hacer una modificación es necesario que el programador entienda la teoría detrás de la solución existente, de forma tal de poder confrontarla con los nuevos requerimientos. Por lo tanto puede ocurrir que la modificación "encaje" con la teoría existente, o bien sea inconsistente con ella y termine siendo un parche desconectado del resto del programa. Pretender que cualquier programador puede fácilmente cambiar la funcionalidad existente viene de pensar en los programas como si fuesen solo texto: "Parte de esa funcionalidad esta hecha en el sistema, simplemente habría que agregarle un par de cosas, debería ser muy sencillo" (total que tan difícil puede ser agregar una líneas de texto). Documentar no es suficiente.

The problem of education of new programmers in an existing theory of a program is quite similar to that the educational problem of other activities (...). The most important educational activity is the student's doing the relevant things under suitable supervision and guidance. In the case of programming the activity should include discussions of the relation between the program and the relevant aspects and activities of the real world, and of the limits set on the real world matters deal with by the program.

Es decir para poder entender un programa existente, es necesario comprender la teoría detrás del mismo. Esta compresión plantea el mismo problema que en otras areas de la educación. Cierto tipo de documentación ayuda, pero la transferencia persona a persona y la "práctica" guiada (pair programming por ejemplo) son más importantes que la documentación. (es como si uno quisiese aprender Análisis Matemático solo leyendo un libro, sin ayuda y sin hacer ejercicios) No hay un método de programación que sea el correcto.

As to the use of particular kinds of notation or formalization, again this can only be a secondary issue since the primary item, the theory, is not, and cannot be, expressed, and so no question of the form of its expression arises. It follows that on Theory Building View, for the primary activity of the programming there can be no right method.

Esto no invalida la aplicación de métodos, lo que indica es que solo son prácticas complementarias. Es decir pretender que uno puede crear buen software siguiendo al pie de la letra un método de desarrollo es erróneo, por que la actividad principal en la creación de software según este punto de vista es la elaboración de la teoría, es decir la adquisición de conocimiento que depende mucho de la persona y del "problema" a enfrentar. Luego en lugar de adoptar un método para la construcción del programa en si, es mejor centrarse en prácticas que ayuden a la construcción de teorías:

the quality of the theory built by the programmer will depend to a large extent on the programmer's familirity with model solutions of typical problems, with techniques of description and verification, and with principles of structuring systems consisting of many parts in complicated interactions.

Por ejemplo design patterns, test driven development y modularización. Cambio en el "status" del programador. Quizás este sea para algunos el punto más controversial, ya que para muchas prácticas de ingeniería de software se asume que la programación es similar a la producción industrial, donde el programador es un componente más de la cadena de producción.

On the Theory Building View the primary result of the programming activity is the theory held by the programmers. Since this theory by its very nature is part of the mental possession of each programmer, it follows that the notion of the programmer as an easily replaceable component in the program production activity has to be abandoned

Esto también plantea un desafío para la educación de los programadores, ya que si bien es importante conocer los aspectos técnicos, se debería poner énfasis en la formación de teorías.