A man can control only what he comprehends, and comprehend only what he is able to put into words. The inexpressible therefore is unknowable. By examining future stages in the evolution of language we come to learn what discoveries, changes and social revolutions the language will be capable, some day, of reflecting.
Stanislav Lem
After years of having this account getting dust over dust, I’ve decided to start using it again. Now with short posts, mainly about software and relative subjects.
As before, I’ll be writing in three languages, mainly english as I live in the US, then spanish as that one is my country language, and finally catalan, just because I like it.
Ya lo han dicho muchos, la realidad, es decir, la descripción que de ella hacemos, depende del observador. Para Foerster la realidad es una cómoda muleta que usamos para hablar de la descripción de la observación (que llamamos simplemente observación).
En un post de Marco Dorantes leo una postulación de las metodologías ágiles como ejemplos excepcionales de la aplicación del pensamiento científico al desarrollo de software, post que encontré poco después de publicar yo mismo uno en el que sostengo que las metodologías ágiles, en particular la XP, pueden verse como aplicaciones prácticas del pensamiento constructivista (constructivismo epistemológico), posición filosófica enfrentada principalmente con el positivismo: el primero postor del método científico al que hace alusión Marco.
En primer lugar, quiero decir que me ha llenado de gusto ver que no soy el único discutiendo acerca de la epistemología aplicada al desarrollo de software. Igual que Marco, estoy convencido de que una posición filosófica puede aportar bastante a las metodologías y a las formas generales de hacer software.
Visto de manera general, el desarrollo de cualquier producto bajo especificaciones de diseño, es decir, diseñado y construido para cumplir una serie de requerimientos, parecería una aplicación práctica de las ideas del constructivismo.
Los requerimientos son expresados generalmente en forma de observaciones: “El sistema ofrece al usuario una lista con las opciones que el usuario tiene permitido utilizar” o “Cuando el usuario solicita al usuario imprimir un informe, el sistema solicita una confirmación antes de proceder”.
Estas observaciones determinan lo que el sistema puede y lo que no puede hacer, es decir, definen lo que la implementación, la realidad del sistema, debe ser y será una vez terminado el desarrollo. Los requerimientos construyen la realidad del sistema. Pero la afirmación de que la construcción de un producto o sistema es una aplicación del constructivismo no tiene nada de sorprendente, pues se trata finalmente de “construcciones” de cosas, en este caso, de software.
El constructivismo toma su nombre precisamente de la construcción de cosas, edificio, máquinas, etc. Decir ahora que la construcción de una casa es una aplicación de las ideas constructivistas es una necia obviedad. Sería como sorprendernos de que las naranjas sean precisamente de color naranja, siendo que este color se llama así por las frutas.
Pero en el caso de las metodologías ágiles las cosas ya no son tan triviales, pues el enfoque constructivista puede verse mucho más allá de la simple construcción de una cosa. Sobre todo si pensamos en las metodologías que tienen como eje la orientación a pruebas (TDD) como es el caso de la XP.
Cuando se trata de personas, todo tiene que ver con ergonomía. Como dice Peter Morville en su libro “Ambient Findability“, la posición de un botón en una máquina, la imagen de una señal de tráfico, la silla Herman Miller que le resolvió su problema de dolor de espalda, todo lo que usamos, todo lo que nos permite trabajar debe ser cómodo, debe ser fácil, debe ser práctico y finalmente, debe ser productivo.
En estos días hemos estado trabajando en un rescate de un proyecto de desarrollo de software. Los rescates son una de esas cosas que no deberían existir, pero que parecen inherentes al medio profesional de los sistemas de información.
Me imagino que hay rescates de todo tipo, pero tengo la creencia de que la gran mayoría tienen su origen en una falta de buenas prácticas y un exceso de malas prácticas.
Existen buenas prácticas que podríamos llamar “sofisticadas” o “exquisitas”, como el uso de metodologías como XP y RUP, el uso de diagramas UML, las métricas de código, etc. De estas hablan muchos libros y muchos blogs, pero todos damos por sentado que las prácticas más básicas están allí de respaldo, esta creencia es tan ingenua como la que tiene un niño en Santa Claus.
Las buenas prácticas elementales son a veces tan generales que son poco discutidas en los libros del tema. Muchas de ellas son aplicables a cualquier persona que trabaja en una oficina, que permanece sentado la mayor parte del tiempo frente a una computadora. Otras se aplican a todos los que trabajamos en entornos colaborativos. Lo cierto es que apenas se les menciona en los manuales de desarrollo de software.
Hoy no voy a hablar de cómo hacer casos de uso o de cómo usar un dashboard de desarrollo, de la integración continua y las pruebas de similitud de código. Hoy quiero reafirmar la importancia de las buenas prácticas más elementales del desarrollo de software. Continue reading
Al que no puede con la sopa... doble ración. 