La mayoría de la gente que se acerca hoy día a un ordenador por primera vez no se sorprende apenas ante las opciones más básicas que el software nos ofrece. Bien porque es muy joven (los niños se inician en la informática de forma totalmente natural) o bien porque ya sabe más o menos qué esperar.
Por eso no se sorprenden ante el que para mí, es el más importante hito de la historia del software: el poder deshacer los cambios. El Undo. El CONTROL+Z (COMANDO+Z si eres de Mac).
Hoy día, la gente escribe, edita, retoca, diseña, <lo-que-sea-que-haga-con-un-programa> y cuando se equivoca le da al “deshacer” y aquí no ha pasado nada. Pero esto no siempre ha sido así, y no hablo de las máquinas de escribir. Yo he llegado a usar, hace años, en mi Amstrad, editores de texto en los que, como te cargases un párrafo, adiós.
Por eso cuando vi por primera vez la opción de “deshacer cambios” me quedé sin palabras. Y no digamos cuando apareció el concepto de deshacer, no sólo el último cambio, si no los n últimos. Creo recordar que la primera vez que lo vi fue en un editor de textos, el AmiPro. Antes que en el Word incluso.
Esta posibilidad de deshacer los cambios, o de poder cambiar lo creado, es visto desde cierto ángulo la piedra angular del software, lo que ha hecho que toda la humanidad se vuelque en hacer que todo sea software en la medida de lo posible. Sí, porque así es más fácil gestionar el cambio.
Si, como yo, eres de los que piensa que en este mundo la única constante es el cambio (el anicca que lo llaman los budistas), entonces entenderás porqué alabo tanto sus virtudes. Si todo cambia, y el software agiliza el cambio, viva el software.
Ojalá el mundo analógico gozase de esta virtud. Y es que, como os voy a contar en este monólogo, yo creo que el mundo analógico tiene mucho que aprender del mundo digital.
El software, como a su vez se “construye” con software, pues se beneficia como nadie de la facilidad para el cambio, y por eso cada muy poco tiempo tenemos nuevas versiones de nuestros programas favoritos (en realidad podría ser mucho más frecuente pero luego están los intereses comerciales).
Y como cambia tanto (porque “no cuesta”) los que nos dedicamos a ello hemos tenido que aprender una serie de doctrinas, patrones y best-practices, para que tanto cambio no nos desmoralice, y podamos gestionar nuestros proyectos de desarrollo de software eficientemente.
Por que si en el mundo analógico todo cambia, no os quiero ni contar en el mundo del software. Hay quien dice (basándose no sé en qué) que el mundo digital, refiriéndose a los ordenadores e internet, va diez veces más deprisa que el analógico. En todo caso eso será hoy día, porque si lo comparamos con la Edad Media, diría diez veces no, mil.
Y es que si hoy día “las cosas” van más deprisa es principalmente gracias a los ordenadores (especialmente al software). Y es que, como intento decir, si consigo dejar de enrollarme, el mundo analógico que ha creado el software, se ha visto rebasado por su creación. El alumno es mejor que el maestro. Y os explico por qué.
Cuando se “creó” el software y se empezó a publicar programas que nos hacían la vida más sencilla, la forma en cómo esto se hacía era imitando un poco al mundo analógico. El mundo del software aprendió mucho de la arquitectura, por ejemplo. De hecho, los famosos patrones de diseño que todos los programadores usamos, son una copia de un concepto, también llamado patrones de diseño, del mundo de la arquitectura. Y no es otra cosa que una serie de reglas y recomendaciones que garantizan un resultado óptimo. Por ejemplo, se podría decir que, a día de hoy, la mejor forma de hacer una salida en una autovía es mediante una rotonda elevada, que permite igualmente entrar y salir a la autovía, así como hacer un cambio de sentido de la forma más simple.
Una rotonda elevada es un patrón de diseño.
Tanto imita (o imitaba) el software a la arquitectura que de hecho se forjó el concepto de arquitectura software y arquitecto software, que, por si no os habíais dado cuenta, es de lo que suelo hablar en este blog, intentando eso sí, que sea relativamente asequible.
Contrariamente a lo que mucha gente piensa, hacer una aplicación grande, de esas que requieren uno o varios arquitectos, no es como hacer un edificio. Es decir, sí, tiene muchas analogías, pero una analogía más precisa es como hacer una gran ciudad.
Una gran ciudad es algo en constante evolución. Cualquier ciudad que haya ido creciendo en los últimos, digamos, 400 años, habrá sufrido cambios increíbles. Ahora tendrá alcantarillado, agua corriente en las casa, electricidad, carreteras asfaltadas, trenes, metro, telefonía por cable, wifi, recogida de basura por succión, etc.
Algunos de estos cambios fueron terriblemente difíciles y costosos de abordar, porque no se pensó en ellos cuando se hicieron cambios anteriores. Digamos que no ha habido una planificación para gestionar el ciclo de vida de la ciudad. Desde hace algunos lustros se empieza a hacer, pero no aún con el mismo empeño con que se gestiona el cambio en la arquitectura software.
Hay ciertas cosas que no se pueden prever, como fue el tsunami del Índico hace unos años. Si lo hubiesen previsto, las ciudades costeras tendrían, entre otras cosas, grandes vías de salida que permitiesen evacuar a la ciudad rápidamente. No se podría haber previsto un tsunami, pero sí algo más genérico: una catástrofe genérica. Pudiera ser una Catástrofe<Tsunami> o una Catástrofe<Terremoto> o Catástrofe<GuerraCivil> por expresarlo en términos Java :-). En cualquier caso, cualquier día puede suceder una catástrofe, que será menos dramática si la ciudad dispone de vías de escape, sean del tipo que sean. Este es el tipo gestión del cambio que SÍ hacemos los arquitectos software y no tanto los urbanistas o alcaldes...
Es decir, cuando diseñamos aplicaciones software, pensamos siempre en el cambio, sea del tipo de que sea, y eso facilita mucho su gestión y su crecimiento de forma organizada, intentando minimizar así los efectos de la crisis del software.
Por supuesto también hay mucho arquitecto software chapuza (esto es, no son arquitectos software) que no planifican bien el cambio, y cuando la aplicación empieza a crecer y crecer se hace cada vez más imposible introducir cambios nuevos sin que éstos afecten a otros puntos de la aplicación. Al final la aplicación hay que tirarla a la basura y empezarla de nuevo. Y ojo, el que sea software no significa que cueste poco rehacerla.
Siguiendo esta línea de pensamiento, veo que las ciudades habría que diseñarlas como si fuesen una aplicación informática. Llenas de interfaces, como el de Vía de Escape. O como el de Zonas Verdes. Hay muchos más: zona urbanizable, terreno industrial, zonas de ocio y compras, espacios para brigadas de actuación rápida, etc. Este último ejemplo es un interfaz, una abstracción, sobre algo concreto como puede ser policía, bomberos, guarda civil, etc. Si yo tuviese que diseñar una ciudad colocaría por el centro, en las arterias principales, con buenas entradas y salidas varios solares sobre los que construir edificios que alberguen estas brigadas. Hoy pueden ser bomberos, pero mañana pueden ser, que sé yo, cazafantasmas que entran y salen con urgencia para aplacar la aparición de pequeños e incómodos seres verdes viscosos. Es un ejemplo absurdo pero ilustrativo. El urbanista/arquitecto software no piensa en cómo será el edificio de la brigada; da igual, porque hoy será una cosa y mañana otra. Sólo piensa en el interfaz, en que tiene que haber zonas especialmente pensadas para esas brigadas.
Mira, se me ocurre que un interfaz que sin querer los países desarrollados han creado, es el de Estación de Servicio. No digo gasolinera, que es una implementación concreta de algo más abstracto como es Estación de Servicio. Se ha creado una red de Estaciones de Servicio donde poder parar y hacer cosas que hay que hacer cada x kilómetros recorridos: repostar, comer, ir al baño, cambiar los pañales al niño, poner a punto el vehículo… Hoy día repostar implica echar gasolina, pero puede que mañana sea echar hidrógeno, o cambiar la batería que alimenta el motor eléctrico. El caso es que ahí están, cada x kilómetros hay una, situadas estratégicamente para lo que pueda necesitarse hoy o el día de mañana.
Esta forma de diseñar las cosas, siempre pensando en lo abstracto y lo concreto, siempre pensando en interfaces para enfrentarse al cambio, es algo que ha desarrollado e impulsado la arquitectura software. Y aunque de forma tímida se venía haciendo en el mundo real, somos los arquitectos software los que le hemos puesto nombre a las cosas y hemos puesto por escrito las reglas para trabajar de esta manera.
Y esta forma de diseñar debería transcender el mundo software para empezar a aplicarse mucho más en el mundo real, aunque lo cierto, es que sólo tiene verdadero sentido en aquellas disciplinas que están en constante cambio, como es el urbanismo, la formación, la medicina, legislación, etc. De esta última tengo que decir que mantiene, en cierto sentido, una gran similitud con la arquitectura software, y es que las leyes manejan también siempre conceptos abstractos que se aplican a cualquier implementación concreta, actual o futura.
Un arquitecto software por ejemplo, nunca construiría viviendas a menos de 2km de la playa, porque el calentamiento global va a elevar el nivel del mar inundando las zonas pegadas a la playa.
Eso es pensar en el cambio. Y eso es, precisamente, la misión de un arquitecto software: tener un ojo siempre en el futuro y pensar en la escalabilidad y en el cambio. Y elegir las tecnologías y diseños que permitan afrontar elegantemente el cambio y sobre todo el crecimiento, para que cuando este llegue, se pueda aplicar sin afectar al resto de la (Ciudad) aplicación.
