Software developmentCrear software no es solo la simple producción de código. Va más allá del hecho de escribir ciertas instrucciones conociendo una sintaxis y una gramática determinada. Entonces, ¿qué es el software? ¿Cómo se hace?

Uno de los que mejor ha tratado el tema de la actividad de programar es Peter Naur, creador de la notación BNF y ganador de un premio Turing (2005), en su artículo “Programming as Theory Building”. Vamos a resumir en qué consiste su idea.

En primer lugar, Naur parte de la noción de Teoría de Ryle. En The concept of Mind, un trabajo clásico de filosofía sobre la naturaleza de lo mental y el comportamiento humano, Ryle desarrolla su noción de teoría como parte de su análisis de la actividad intelectual y la manera en la que esta difiere de una actividad simplemente inteligente.

Lo que caracteriza a la primera frente a la segunda es que para llevar a cabo algún tipo de ejercicio intelectual, una persona ha construido una teoría, entendida como el conocimiento que debe tener, no solo para hacer algo de forma inteligente y hacerlo bien según un cierto criterio, sino también para tener la capacidad de explicar, responder preguntas, argumentar o justificar la actividad que la concierne. La teoría le permite detectar y corregir fallos, aprender de ejemplos, etc.

Se puede apreciar que la noción de teoría no descansa en la idea de que un comportamiento inteligente depende de la adhesión a reglas o métodos. Por ejemplo, para comprender la teoría de la mecánica newtoniana no es suficiente saber que la fuerza es igual a la masa por la aceleración, sino que se debe tener una comprensión de la manera en que las leyes de Newton se aplican a aspectos de la realidad, y de esta forma reconocerla y aplicarla a otros fenómenos similares.

A partir de aquí, Naur toma prestada esta noción y establece que el programador debe construir una teoría sobre cómo ciertos aspectos del mundo van a ser modelados, representados y manejados por un sistema de software. Esta persona será capaz de responder a las demandas de modificación o adaptación a cualquier cambio de requisitos.

Implicaciones en la “mantenibilidad” del software

La vida de un software después de su entrega (es decir, su mantenimiento, que es lo que ocupa la mayor parte del ciclo de vida), dependerá de que las personas encargadas tengan esta teoría. Si el equipo que la posee se disuelve, con ellos se pierde la comprensión profunda de esa materialización en forma de código de un problema real, y se produce la muerte del software. Puede seguir ejecutándose, pero el resultado será cada vez más costoso de modificar o añadir funcionalidades, lo que incrementaría la deuda técnica.

La teoría es una propiedad colectiva que comparte el equipo original. Como sostiene Naur, lo que se requiere para que una nueva generación de programadores puedan seguir extendiendo la vida del software, no es que se familiaricen con el código y la documentación, algo que sin duda puede ayudar; sino que tengan la oportunidad de trabajar en contacto con estas personas, y conozcan el funcionamiento del software. Que aprendan cómo sus respuestas inesperadas o sus modificaciones pueden entenderse bajo el paraguas de la teoría. El factor humano y la comunicación se convierten en una parte muy importante en el desarrollo del software.

Una de las consecuencias más importantes según este punto de vista es que la reconstrucción de la teoría de un software a partir de la documentación es imposible. O la ya clásica Ley de Brooks, que muestra cómo añadir más efectivos a un proyecto de software en retraso lo atrasará todavía más.

Conclusiones acerca de la “teoría”

El hecho de que una parte considerable del tiempo de desarrollo se dedique a entender el código es un problema intrínseco al software. De este modo, aunque no sepamos nada de la Theory Building de Naur, ni de Ryle, lo que estamos haciendo, sin saberlo, es intentar reconstruir la teoría; crearnos esa visión mental.

Y es que el software pertenece al ámbito de la actividad intelectual, y no meramente al productivo. Por tanto, no deja de ser un caso particular del problema tradicional de la creación artística o intelectual.

Un ingeniero experimentado, con una comprensión profunda del dominio del problema, podrá resolver cuestiones relacionadas con la teoría. Y por suerte, en Teldat contamos con ingenieros de este tipo. ¿Por qué les surgen más ideas, mejores y más rápido?

El escritor austríaco Stefan Zweig, que se sintió atraído durante toda su vida por el misterio de la creación, no del software sino artística, dijo que “de todos los misterios del universo, ninguno más profundo que el de la creación […] ¿y quién pudiera decir de dónde proceden las ideas?”. En el caso del software, al menos, podemos decir que proceden en, parte, de la teoría.

Referencias:

– Peter Naur, Programming as Theory Building
– Ryle, G. The Concept of Mind
– http://www.javiergarzas.com/2017/05/comprendiendo-que-es-crear-software-y-como-no-es-una-actividad-de-produccion.html


Sobre el autor

Javier Marchan
Javier Marchan
Ingeniero de software en el departamento de I+D, desempeña tareas en el desarrollo del Sistema Operativo de Internetworking de Teldat

Comparte este post

Tweet about this on TwitterShare on LinkedInShare on Google+Email this to someone

Nuestras Soluciones Relevantes