Si has estudiado programación, por ahí por tus recuerdos debe andar el nombre de Peter Naur, más bien recordarás el apellido, te debe de sonar de la notación BNF, la “Backus-Naur Form”. Aparte del BNF, de ganar un premio Turing y de otras cosas más, en el 85 Naur publicó uno de los artículos más esenciales para entender la actividad de programar (y que yo haría extensible a otros trabajos de carácter intelectual): el “Programming as Theory Building”.
Por cierto, un artículo bastante desconocido para mucha gente, con la repercusión que tuvo en su día, y a día de hoy difícil es ir de «muy ágil» y que la «Theory Building» no te suene (pero pregunta por ahí a ver cuántos la conocen).
El artículo es una reflexión sobre qué es programar, como NO es «producir» algo (el código), es un profundo razonamiento sobre lo poco útil de documentar, sobre cómo fluye el conocimiento entre la gente que ha trabajado en el desarrollo de cierto software, etc.
Uno de los puntos más profundos de su planteamiento es que la programación debe considerarse una actividad mediante la cual los programadores forman o logran cierto tipo de visión mental, lo que él llama «teoría» (que no te confunda la palabra, va más en el sentido de actividad intelectual). Y que contrasta con la idea más común y popular… que la programación es esencialmente la producción líneas de código y documentos asociados.
En el «abstract» del artículo Naur ya dice (summarized and translated by jgarzas)…
El objetivo principal de la programación no es crear programas, sino hacer que los programadores construyan teorías [esquemas mentales] sobre la manera en que problemas se resuelven mediante la ejecución del programas.
El objetivo principal de la actividad de programar es crear un esquema mental sobre la resolución de un problema (la llamada teoría), que se translada a líneas de código, pero lo principal es la creación de un esquema mental problema – solución (que puede ser mejor o peor). Y no la «producción» de líneas de código.
El código no es la clave de un equipo de programadores, de hecho está en constante cambio, el verdadero objetivo de los miembros de un equipo de desarrollo es comprender en profundidad el problema que están tratando de resolver y la solución para resolverlo. Si el equipo construye una teoría apropiada, su software será mejor y los miembros del equipo más fácilmente llevarán a cabo modificaciones y mejoras.
Naur subraya hasta qué punto la Teoría es importante:
Durante la vida del programa, el equipo de programadores que posea su Teoría [ese esquema mental] tendrá el control del programa y, en particular, el control sobre todas las modificaciones. La muerte de un programa ocurre cuando el equipo de programadores que posee su Teoría se disuelve. Un programa muerto puede seguir siendo ejecutado, pero el estado de la muerte se hace visible cuando las demandas de modificaciones del programa no pueden ser respondidas inteligentemente. El renacimiento de un programa es la reconstrucción de su teoría por un nuevo equipo de programadores.
Para todo esto de la «Teoría», Naur tira de ideas de la filosofía, concretamente las de Ryle (aquí no voy a entrar mucho, para no perderte, si quieres más lee el artículo original), el que posee la teoría (ese conocimiento) sabe cómo hacer ciertas cosas, explicarlas, poner ejemplos (lo que recuerda mucho al tema de las metáforas de eXtreme Programming).
El concepto de Teoría de Naur dice que crear software es un esfuerzo individual y colectivo para entender el mundo y cómo el software puede resolver algunos de sus problemas. Por ello hablar, compartir, tener cosas (como historias de usuario) que nos ayuden a hablar y recordar, son actividades como la que más a la hora de crear software.
Y de todo esto de la «teoría», el artículo saca algunas conclusiones, más las que te puedes plantear tú mismo, por ejemplo, que la continua adaptación, modificación y corrección de errores depende esencialmente del conocimiento, la Toería, que poseen los programadores. O que la documentación es algo secundario, porque para que un nuevo programador llegue a poseer la Teoría es insuficiente la documentación, para entender como trabajar, modificar, mantener, etc., un programa debes involucrarte en la Teoría que lo creó y eso no puede dártelo un documento.
Lo que no debes olvidar… el software no es una actividad de producción
En esencia, la verdadera visión, el pensamiento ágil, es de software como Teoría (esquema mental), no como producción. Pero en muchas ocasiones te vas a encontrar gente que habla de agilidad en el sentido de un método más de producción y, ojo, las prácticas (ágiles) no son más que una manera de expresar valores y principios, no son las únicas posibles.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
en mi opinión
aunque es un clásico el tema, esta es una buena revisión más; de hecho leyendo
«El objetivo principal de la actividad de programar es crear un esquema mental sobre la resolución de un problema (la llamada teoría), que se traslada a líneas de código, pero lo principal es la creación de un esquema mental problema – solución (que puede ser mejor o peor). Y no la “producción” de líneas de código.»
me hace repensar e incluso me trae el concepto peligroso que una palabra al final es un signo de signo; y de ahí que mejor otro lenguaje como el de las metáforas y obtener esquema mental frente a párrafos y párrafos en cualquier lengua
Hola Javier:
Valoro mucho tu artículo ya que he sido programador por mucho tiempo y considero que, en efecto, no somos máquinas de producción. De hecho nos enfocamos en el problema, buscamos una solución y para llegar a ello usamos líneas de código (algunas más eficiente que otras). Esto tiene mucho que ver con lo que ya has comentado sobre que Construir Software no es como Construir X cosas. No es una actividad productiva sino teórica (tomando tu concepto de este término). Asimismo, cuando se habla de «muerte» entiendo se te refieres a que la muerta de la idea original del código cuando pasa de una mano a otra. Esto pasa mucho cuando se rotan los programadores (no en el marco de XP, porque en XP todos tienen un estándar como equipo) sino cuando pasa el tiempo y llegan programadores nuevos al equipo.
Interesante, muy de acuerdo sobre como la creación de software no es una «actividad productiva», sin embargo creo que decir que la documentación es secundaria, igual me parece bastante arriesgado, sobre todo pensando en estas situaciones donde el personal rota. Creo que el problema hoy es que se documenta incorrectamente, sin embargo una buena documentación debería ayudar bastante a gestionar un software. Quizas un tema de discusión debería ser ¿qué es bueno documentar?¿cómo se documenta?¿cuándo se documenta? ¿cómo se documenta? etc. o estoy muy perdido??