Notas sobre "Episodio 1: ¿Qué es Diseñar y cómo hacer que un diseño nos enseñe?" del webinar Diseño a la Gorra de Hernán Wilkinson.

gistfile1.txt

Algo que me gusta es que Hernán nos invite a plantearnos preguntas como ¿qué es el desarrollo de software? o ¿qué es el diseño de software?. Existen multitud de visiones o filosofías sobre qué es el software y me parece muy importante que los desarrolladores conozcamos la historia y estas distintas ideas y nos posicionemos también personalmente, respondiendo a estas preguntas por nosotros mismos. De nuestra visión sobre el software, incluso de qué papel juega o debería jugar en la sociedad, va a depender nuestra respuesta a muchas otras cuestiones, como:

* ¿Cuáles son los principales problemas que hay que resolver en el desarrollo de software?
* ¿Qué aspectos del desarrollo son los que consideramos más importantes?
* ¿Qué es para nosotros software de calidad?
* ¿Cómo debería ser el desarrollo de software en el futuro?
* ¿Qué papel político y social debería tener el software?
* ¿Qué tipo de herramientas preferimos para trabajar?

Por ejemplo, si uno acepta la visión reduccionista que define un programa como una secuencia de instrucciones que el programador escribe para controlar el funcionamiento de una máquina, entonces la programación se entiende como una producción de código fuente (texto en definitiva) y probablemente su entorno de desarrollo ideal será un IDE tradicional, que básicamente es un editor de texto.

Creo que nuestra filosofía sobre el software influye en todos y cada uno de los aspectos involucrados en el proceso de desarrollo. Por lo tanto, es clave hacerse estas preguntas y reflexionar sobre ello.

¿Cuál es tu "visión" personal sobre el software? Estaría bien que las podamos compartir y debatir sobre ellas.

Si alguien está interesado en leer sobre la historia de las diferentes filosofías sobre el software, recomiendo estos dos libros de David West. Están sesgados a favor de su propia visión, como él mismo reconoce, pero aún así hace un repaso de diferentes tradiciones de pensamiento:

* Object Thinking: https://www.goodreads.com/book/show/43940.Object_Thinking
* Design Thinking: https://www.goodreads.com/book/show/36899773-design-thinking

En cuanto a la visión que defiende Hernán ("el software como un modelo computable de un dominio de problema") es la típica de su tradición que, como Smalltalker de pro, es el pensamiento orientado a objetos. No es cualquier orientación a objetos, sino el tipo de tradición dentro de OO conocida como "object-behavioral".

Personalmente, y aunque me identifico bastante con la orientación a objetos tal y como la entienden Hernán y otros, como Rebecca Wirfs-Brock, que creó la idea de Responsibility-driven Design. Mi visión (actual) del software incluye estos otros elementos que en la visión de Hernán no se mencionan:

1. Creo que nuestra actividad principal como desarrolladores es la elaboración de teorías, sobre el propio problema y sobre posibles soluciones basada en procesos computables. Además, estas teorías no pueden transmitirse a través de código fuente. Esta visión tiene importantes consecuencias, como por ejemplo, sobre la economía del mantenimiento del software. Si se quiere profundizar en esta línea de pensamiento recomiendo el clásico de Peter Naur "Programming as Theory Building": http://pages.cs.wisc.edu/~remzi/Naur.pdf

2. Estamos demasiado enfocados en el mundo de la solución y prestamos muy poca atención al análisis del problema del mundo real.

Aunque en la descripción de Hernán se menciona el "dominio de problema", después afirma que "el diseño es el código" y esa es la parte que no comparto. No porque no crea que hoy en día sea de esa manera, sino porque creo que no debería ser así. Tampoco porque crea que habría que aplicar unas fases de análisis y de diseño en cascada. De hecho, estoy bastante acuerdo con la idea de "seamless development" que surgió en oposición al proceso de desarrollo compartimentado; es decir, que sería deseable trabajar en un mismo marco conceptual y notacional para estas actividades. Sin embargo; usar el código, aunque sea orientado a objetos, como este marco común, me parece que está demasiado orientado a la solución.

Muchas veces cuando se habla de que se ha comprendido y descrito el problema, la gente se refiere a hacer creado un modelo, pero estos modelos realmente forman parte de la solución. Es un problema típico de "el mapa no representa el territorio".

Sobre este tema me gusta el trabajo de Michael Jackson (no es el cantante) y de su hijo Daniel:

* Design by Concept: https://www.goodreads.com/book/show/45029338-design-by-concept
* Problem Frames: https://www.goodreads.com/book/show/292011.Problem_Frames

3. Convergencia usuario-desarrollador (end-user development o citizen development)

Mi opinión es que el software también debe jugar, de hecho juega, un papel social y político. Me gusta la idea de que el software nos mejore y potencie como seres humanos (la idea de Doug Engelbart de "Augmenting Human Intellect"), pero creo que esto no puede suceder si la capacidad de crear software está limitada a un grupo reducido de personas. Actualmente, los desarrolladores somos algo así como escribas modernos. Es necesario evolucionar a un modelo de software y de industria de software en el que los usuarios finales puedan tener la propiedad del mismo y adaptarlo o modificarlo fácilmente según sus necesidades cambiantes.

4. Diseño participativo

Creo que la elaboración de la/s teoría/s en que consiste el desarrollo según la visión de Theory Building, debería ser un proceso colaborativo; tanto con otros diseñadores de software, como con usuarios finales y expertos de dominio. Existen ya algunas herramientas de diseño colaborativo: tarjetas CRC, event storming, domain storytelling, etc. y en otra escala: pair programming o revisiones de código.

Sin embargo, echo en falta que el proceso sea constantemente colaborativo y ofrezca feedback loops inmediatos que nos ayuden a reflexionar sobre nuestras teorías y diseños, sin tener que esperar días para ver prototipos funcionales.

Esto está alineado con las ideas de la llamada escuela escandinavia de diseño. En particular, con el "diseño participativo" del que habla Pelle Ehn: https://www.uio.no/studier/emner/matnat/ifi/INF9200/v10/readings/papers/Ehn.pdf


Nos faltan las herramientas que nos ofrezcan un marco conceptual apropiado para poder enfocar nuestros esfuerzos en el problema y en la "forma de las soluciones" (diseño), en lugar de en los detalles de bajo nivel de la solución pensados para la máquina. Hace falta un nuevo salto de nivel de abstracción, como otros que se han producido en el pasado. Además, debería ser posible que estructuremos estas teorías de conocimiento de forma independiente de la estructura interna que tenga la solución (clases, funciones, módulos, etc.).

Finalmente, estas herramientas deberían facilitar el diseño participativo y permitir a cualquier usuario participar de la "teoría" y modificarla fácilmente cuando lo necesite, sin depender de ningún programador para ello, ya que el usuario poseerá también la "teoría" con que se creó la solución.

En Blue Plane, a la visión de esta herramienta futura la llamamos "Software Atelier". A la liberación añadida de no tener que crear el software en el medio actual; es decir, escribiendo (ya sean símbolos, textos o gráficos), sino en un nuevo medio más dinámico (véase DynamicLand de Bret Victor: https://dynamicland.org/) lo denominamos "Heidegger's Hut", en referencia a la cabaña que usaba Heidegger para pensar.

— Rafael Luque, 21 septiembre 2020