Los Sistemas Heredados como Ciudades Viejas

Translations: en - gnome, recompiler, urbanism

Escribí un artículo, Legacy Systems as Old Cities (Los Sistemas Heredados como Ciudades Viejas), para la revista The Recompiler. A 20 de años de su existencia, ¿es GNOME un sistema heredado? ¿Es diferente del software heredado para mainframes porque "todo el mundo" puede modificarlo? El software que vive por mucho tiempo, ¿tiene los mismos patrones de cambio que las ciudades y artefactos físicos? ¿Podemos aprender de los oficios de construcción y del urbanismo para mantener software a largo plazo? ¿Podemos convertir el software heredado en una buena herencia?

El artículo original en inglés está aquí.

Además, me permito esta oportunidad para recomendar la revista The Recompiler. Es la revista técnica más agradable que leo hoy en día. También tienen un podcast, que es excelente.

Aquí va una traducción al español del artículo.

Los Sistemas Heredados como Ciudades Viejas

Los sistemas heredados (legacy systems) tienen mala reputación entre los computólogos. Casi nadie quiere trabajar en software para mainframes en COBOL. Cuando compras un boleto de avión en persona, toda la mecanografía intensa que hace el agente de viajes se debe a SABRE, un sistema heredado que se usa para buscar y reservar boletos de avión; y uno puede pensar que la comisión que cobran los agentes de viajes se debe precisamente al trabajo que cuesta aprender a usar ese software. Puede ser que conozcamos historias de terror sobre una compañía tristona que simplemente no puede abandonar Windows 95, o Windows 3.1, porque tienen una pieza de infraestructura crítica que jamás se actualizó para correr sobre un sistema más nuevo.

Es difícil imaginarse tener la posibilidad de controlar el destino de esos sistemas. Son Demasiado Grandes Para Morir, y están plenamente fuera del alcance de la "gente de todos los días".

Pero, ¿qué hay de los sistemas heredados que están más cerca de nosotros? ¿Qué hay, en específico, del software libre que tiene una larga historia?

Hace unos 20 años leí un librito maravilloso que se llamaba "20 Años de Unix", y en ese entonces no era precisamente una edición reciente. En ese tiempo yo estaba involucrado en la creación del proyecto GNOME, el cual casi 20 años después puede presumir de ser ubicuo en el mundo del software libre, y que es parte del núcleo de los escritorios Linux. Puedes ver cómo se ve GNOME en esta página — hay un pantallazo general del escritorio ahí.

El GIMP (GNU Image Manipulation Program) es de 1995, y en ese tiempo el GIMP usaba Motif como biblioteca para su interfase gráfica. Aun entonces se consideraba a Motif como software heredado, indeseable y propietario. Los autores del GIMP escribieron desde cero otra biblioteca para interfases gráficas (GUIs), una biblioteca libre y llamada GTK+, de la cual salió GNOME en 1997. En 1998 ó 1999 uno de los voluntarios que contribuían a GNOME, Raph Levien, comenzó a escribir libart, una biblioteca para dibujo vectorial de alta calidad. Más tarde, y gracias a Lauris Kaplinski, esa biblioteca dio lugar a Sodipodi, un programa de ilustración vectorial, y éste a su vez y gracias a muchas otras personas, resultó en Inkscape — el cual completa el dúo dinámico del diseño gráfico junto con el GIMP.

Existe una larga historia de software que es bien querido, o que es lo suficientemente útil, como para que haya gente que lo mantenga y actualice de forma continua para que corra sobre infraestructura más nueva.

Ciudades

Ahora, permíteme llevar tu atención a algo más tangible: las ciudades. Por supuesto que hay ciudades con miles de años de historia: Roma, Beijing, París, El Cairo, la Ciudad de México, Estambul. ¿Y con cientos de años? El Puerto de Veracruz, Sevilla, Tokio, Berlín. Me dio risa leer un artículo que hablaba sobre cómo "Vancouver (Canadá) sólo tiene 300 años...", lo cual indicaba que es especial precisamente porque es "nueva", a diferencia de las ciudades normales, que son viejas. No sé si exista esnobismo alrededor de "mi ciudad es más vieja que la tuya", pero a veces parece que sí lo hay.

Y sin embargo, nadie le llamaría decrépitos e indeseados a esos lugares, ni les llamarían un mal legado. ¡Ahí vive gente! Cada quién mantiene su partecita de la ciudad lo mejor que puede, aun si sólo es su casa. Sus gobiernos hacen un trabajo uniformemente bueno, o uniformemente mediocre, por mantener la infraestructura. Algunas ciudades tienen mucho mejor infraestructura que otras. Siempre me llenó de orgullo perverso que el agua de la llave en la Ciudad de México, donde solía vivir, es perfectamente limpia y potable — mientras que el agua de la llave en París es turbia y de dudosa potabilidad... al menos para mis estándares tercermundistas. (Por supuesto, los parisinos responderían que su sistema de metro y tren suburbano es mucho, mucho mejor que el de la Ciudad de México, y estarían 100% en lo correcto.)

De vuelta al software — en el mundo de GNU/Linux solíamos burlarnos de Windows por la forma primitiva en que ahí se instalan y manejan los paquetes, a comparación de nuestros RPM y DEB. Sin embargo, hoy en día estamos intentando alcanzar a Android e iOS, que tienen paquetes donde el software corre aislado del resto del ambiente (¡y una infraestructura para poderle pagar a los autores del software, aunque está sesgada a favor de Apple y Google!), a comparación de los cuales nuestros RPM/DEB son completamente primitivos y económicamente injustos, pues no hay forma de que los autores reciban compensación monetaria.

Ha habido mucho análisis sobre el efecto de los proyectos de "renovación urbana" del siglo XX. Jane Jacobs, en su Muerte y Vida de las Grandes Ciudades, escribe en detalle sobre los barrios históricos que fueron demolidos para construir grandes edificios de departamentos, y cómo fueron un desastre de manera uniforme. También habla de lugares en donde los habitantes se rehusaron a ser desplazados, donde luego hicieron el mantenimiento diario ellos mismos, y como resultado ahora viven en una zona altamente codiciada de su ciudad. También habla sobre casos donde llega dinero súbitamente a la ciudad, y barrios que eran únicos y llenos de vida se gentrifican y dejan de existir, y se convierten de manera uniforme en trampas turísticas globalizadas.

En una escala más pequeña, hay un libro fabuloso, Cómo Aprenden los Edificios, de Stewart Brand. El libro describe qué pasa con los edificios después de ser construidos, después de que las personas se instalan en ellos y comienzan a adaptar el edificio a sus necesidades (¡necesitamos re-hacer el cableado eléctrico! ¡necesitamos meter cables de red!); después de que los edificios cambian de dueño o de usuarios o de propósito (¡esta fábrica ahora son departamentos! ¡Esta estación de tren abandonada ahora es un centro comercial!); después de que sufren remodelación o expansión o contracción (¡esta casa ahora tiene un cuarto para rentar en lo que era el garage! ¡este restaurante ahora es un café con librería!).

Uno de los conceptos más interesantes del libro es que los edificios tienen diferentes "capas de cambio", y cada capa cambia a un ritmo diferente: Sitio, Estructura, Piel, Servicios, Plano de la Distribución y Cosas.

El Sitio es lo más difícil de cambiar; está definido por el terreno mismo y por los lotes catastrales definidos por la ley.

La Estructura permanece en su lugar desde que el edificio se construye — los cimientos y los elementos estructurales principales como columnas y vigas. Sí es posible cambiar la Estructura, pero casi siempre es costoso, y requiere de tiempo y habilidad técnica. Las estructuras de buena calidad, cuando se les da mantenimiento, pueden durar por siglos. Las estructuras de mala calidad, sólo duran unas décadas.

La Piel es la superficie exterior del edificio. Pintura, tejas, ladrillos reales o falsos. Estos elementos tienen una vida de unas cuantas décadas y necesitan mantenimiento o remplazo regular.

Los Servicios son el cableado eléctrico, cableado de comunicaciones, ductos, plomería, ventilación y aire acondicionado y las partes móviles como elevadores o escaleras eléctricas. Todos necesitan mantenimiento regular o remplazo.

El Plano de la Distribución es cómo está dividido el espacio interior — muros y ventanas, pisos, techos, puertas. La gente los cambia con frecuencia. Una Estructura bien hecha permite que estos elementos se cambien fácilmente.

Por último, las Cosas son con lo que interactuamos a diario: muebles, adornos colgados en las paredes y toda la parafernalia de la vida diaria, del trabajo, y de descanso. Es fácil cambiar de lugar un librero o una mesa: es muy factible experimentar con varias configuraciones en poco tiempo hasta que encuentras con una que te gusta. Este tipo de experimentación es difícil de hacer con la Piel si sólo vives en el edificio (¿tienes la habilidad para cambiar mosaicos?), y mucho más difícil de hacer con la Estructura (¿tienes dinero para demoler un muro y construir uno nuevo? ¿tienes permiso para hacerlo?).

Las Capas de Cambio en el Software

Yo quiero pensar que el software es igual que lo anterior. Tal vez no sea posible hacer una analogía idéntica al Sitio/Estructura/Piel/Cosas, pero intentémoslo.

Un programa de computadora supone un cierto entorno: puede ser el sistema operativo en el que corre, las interfases de programación (APIs) con las que está construido, e incluso el lenguaje de programación en que está escrito. Los programadores tenemos un montón de trucos, técnicas y bibliotecas para para hacer el software más transportable, pero cambiar un programa de sistema operativo casi siempre es una tarea grande. Cambiar el lenguaje de programación es más o menos igual de difícil que cambiar el Sitio de un edificio: se requiere una re-escritura casi completa, lo cual es similar a una demolición y reconstrucción.

¿Y la Estructura? Estamos muy familiarizados con la estructura de los programas de computadora. Se define durante la batalla entre el diseño y la implementación, y depende del propósito del programa y sus flujos de datos principales. Un juego necesita una estructura robusta de concurrencia, para manejar gráficos y sonidos y conductas, todo al mismo tiempo. Un programa de dibujo necesita almacenar grandes cantidades de datos gráficos y debe poder pintarlos rápidamente. Un servidor de web necesita leer datos rápidamente de un almacén de datos, y mandarlos rápidamente a la red. Cambiar la Estructura a gran escala de un programa es trabajo duro, y puede requerir que uno refactorice muchas de las partes pequeñas del programa para que puedan ser posibles los cambios a la estructura principal.

¿Y la Piel? Hacer cambios visuales a los detalles de la interfase de usuario puede ser tan sencillo como cambiar unas constantes de colores o una cadena de texto, o puede requerir más trabajo en la infraestructura — para poner animaciones donde antes no las había, o para cargar iconos vectoriales cuando antes sólo se podía hacer con mapas de bits.

Tal vez cambiar las Cosas es como cuando no cambias la lógica del programa ni la estructura, sino que nada más mueves controles en la pantalla.

La analogía entre software y edificios no es perfecta, pero creo que la lección principal que podemos aprender de los oficios de construcción es que las cosas pueden y van a cambiar a diferente ritmo, y que la vida de los habitantes/usuarios/desarrolladores será mucho más fácil si el diseño del sistema toma en cuenta estas tasas de cambio diferentes. Por fortuna, en el software es fácil refactorizar las cosas para que luego se puedan modificar fácilmente, a diferencia del material físico de los edificios... y siempre hay función de "deshacer".

GNOME

Ahora quiero hablar sobre el "software heredado" en el proyecto GNOME, que es donde trabajo.

Cuando comenzamos el proyecto GNOME, en 1997, una de las primeras cosas que escribimos fue Gnome-panel. Éste es la barra horizontal que salía en la parte inferior de la pantalla, parecida a la de Windows 95, y que contenía el lanzador de programas, la lista de ventanas abiertas, y el reloj del escritorio. Al menos, esa era la intención. Nuestro panel, como el del proyecto KDE, era muy configurable y soportaba "applets". El resultado de esto, ahora que ya sabemos algo de usabilidad y de cómo evoluciona el software libre, fue un completo desastre que era difícil de usar: había decenas de applets disponibles, unos seis diferentes tipos de relojes, y no había una buena configuración inicial por defecto. A la gente le dábamos una caja llena de piezas sueltas, y los usuarios tenían que ensamblarlas hasta obtener algo útil antes de poder usar el escritorio.

En ese entonces no teníamos un manejador de ventanas integrado — el software que dibuja los marcos de las ventanas y sus barras de título, para que uno pueda arrastrarlas y cambiarles el tamaño. Usábamos cualquier manejador de ventanas "tradicional" que hubiera disponible para X11, y algunos de ellos resultaron ser preferibles al ser más fáciles de configurar las necesidades de GNOME. Estas necesidades eran diferentes del escritorio por defecto en X11, un escritorio en blanco y nada más con ventanas encima. Nosotros teníamos un panel (o más de uno) que no debía cubrirse con otras ventanas. Teníamos cajas de diálogo que querían estar centradas sobre su ventana principal. Queríamos que al los eventos de ratón sobre el fondo del escritorio se transfirieran al manejador de archivos, para que el usuario pudiera manipular iconos en el escritorio... e incluso esto no funcionaba desde un principio, porque sencillamente no se había hecho antes en sistemas con X11.

Como con muchas otras cosas, la integración de deveras comenzó a ocurrir cuando se le metió dinero a GNOME. Red Hat formó un equipo para desarrollo exclusivo de GNOME. Carsten "Rasterman" Haitzler trabajó ahí en el manejador de ventanas Enlightenment, y lo llevó de ser una idiosincrásica joya visual a ser una solución bien integrada con el resto de GNOME. Junto con KDE desarrollamos la "Especificación de Manejadores de Ventanas", lo cual hacía más fácil evaluar o implementar manejadores de ventanas que sí funcionaran para escritorios modernos — con iconos para representar archivos, ventanas que se podían centrar, escritorios virtuales múltiples, y todo eso a lo que ya estamos acostumbrados.

Años más tarde, Enlightenment empezaba a mostrar sus limitaciones. En la mente colectiva, se estaba acercando peligrosamente al territorio del "software heredado". El código era frágil y difícil de cambiar. Los controles auxiliares de las ventanas — como los botones para minimizar/maximizar/cerrar — no tenían el mismo estilo visual que el resto del escritorio. Enlightenment tenía soporte para ser un escritorio completo por sí solo, pero esto a veces chocaba con el deseo de GNOME de ser el escritorio.

Terminamos sustituyendo Enlightenment por Sawfish, lo cual fue un cambio doloroso y difícil. Sawfish no era un manejador de ventanas perfecto, pero era más fácil de modificar y desarrollar, pues estaba escrito en Lisp, un lenguaje de más alto alto nivel que C. Usaba GTK+, la biblioteca de controles gráficos de GNOME, para cosas como los menús que aparecen al apretar el botón derecho del mouse sobre el título de una ventana. Sawfish hacía una buena labor para ser compatible con las idiosincrasias de GNOME, como el de tener áreas de la pantalla que no debían ser cubiertas con otras ventanas.

Sin embargo, Sawfish era todavía demasiado configurable. Había combinaciones de opciones que no resultaban en comportamiento razonable, aun tomando en cuenta las preferencias de la gente. Había detallitos en la forma en que se integraba con GTK+ que hacían que los menús aparecieran muy lentamente en algunas situaciones.

Algunos años después, volvimos a cambiar de manejador de ventanas. Metacity era un manejador nuevo, estaba escrito desde cero en C (desafortunadamente), pero tenía "opiniones" sobre lo que debía ser una buena configuración por defecto, y tenía tan poca configurabilidad como fuera posible sin que fuera una camisa de fuerza. ¡Funcionaba realmente bien! Era pequeño, rápido, y aunque no fuera tan fácil de desarrollar como Sawfish, se acoplaba mejor a las metas de GNOME.

... y por supuesto, lo cambiamos para GNOME 3.

De hecho, cambiamos tanto el manejador de ventanas como el panel al mismo tiempo: Gnome-shell, que es responsable del escritorio principal hoy en día, es una combinación de un manejador de ventanas y un ambiente de escritorio. Nos da el "Sitio" sobre el cual se puede construir el resto de GNOME, al menos en términos de la lotificación del área de la pantalla.

Gnome-shell no está (re)escrito desde cero, afortunadamente. Metacity había ido evolucionando poco a poco, a la par de la funcionalidad de X11. Primero se le añadió una rama experimental para dibujar el contenido de las ventanas usando texturas de OpenGL. Luego, el motor de dibujo específico a X11 se remplazó con un motor genérico y con soporte para animación, construido sobre OpenGL. Este motor se llama Mutter — abreviación de "Metacity y Clutter" (una biblioteca para hacer animación pseudo-3D con OpenGL) — y no es un manejador de ventanas completo, sino que es una biblioteca que contiene el núcleo necesario para escribir manejadores de ventanas.

Gnome-shell es un montón de JavaScript que envuelve al motor de Mutter para manejo de ventanas, y le añade las decoraciones a las mismas, pone un panel (que ahora está en la parte superior de la pantalla, y tiene una configuración fija), y tiene modos especiales como la Vista de Actividades (parecida al Exposé de Apple).

Se reutilizó muy poco del código de Gnome-panel. Ahí había muchísimo código para manejar el espacio en pantalla de los applets sobre la barra principal, mucho código para dibujar paneles de diferentes estilos y con comportamiento diferente... y todo eso se descartó para el nuevo escritorio (pero no se tiró a la basura - continúa leyendo). Gnome-shell dibuja su "panel" de una sola forma bien definida, sin que uno tenga que configurarlo primero, y viene con un conjunto bien definido de controles: el botón de Actividades, un reloj, y un par de menús con opciones para accesibilidad, mapa del teclado, y opciones de red/volumen/salir de sesión. Eso es todo.

Gnome-shell soporta extensiones para que la gente pueda añadirle funciones al escritorio original. La meta es que el código que viene de fábrica funcione bien, y cualquier funcionalidad extra sea responsabilidad de terceras personas. Nos hemos alejado de la mentalidad de "una caja con piezas" y nos hemos acercado al modelo de "te damos algo que funciona bien de fábrica, y te damos una infraestructura para personalizarlo".

En este punto tal vez tengas una objeción: no te he dicho nada sobre software heredado, ¡sólo te estoy diciendo cómo ha evolucionado GNOME! Pero si te acercas a la cronología del desarrollo, como si te acercaras a un fractal, verías que en efecto — en varios puntos el software se estaba volviendo heredado, que nadie lo quería y que era difícil de modificar. Sí que tuvimos algunas demoliciones y reconstrucciones, pero no amamos al 100% ninguno de los resultados.

No fue sino hasta que refactorizamos Metacity para soportar OpenGL, y que luego lo convertimos en una biblioteca, y la cual luego envolvimos en un lenguaje de alto nivel, que las cosas comenzaron a rodar más suavemente.

El patrón fue este: refactorizar para modernizar; refactorizar para convertir un programa en una biblioteca; subir un nivel de abstracción y usar un lenguaje de más alto nivel para implementar la parte restante, que no es tan difícil de escribir como el núcleo.

Entonces, ¿qué hay de Gnome-panel? GNOME dejó de desarrollarlo justo antes del cambio a GNOME 3.0. Sin embargo, GNOME 2 era código bueno, y lo usaba mucha gente. Se lo cedimos al proyecto MATE, que quería mantener viva la infraestructura de GNOME 2; más tarde lo llevaron en la dirección que quisieron. Es interesante ver cómo ha evolucionado ese código. Es lindo ver que el código no se murió: a diferencia del software propietario, que se muere cuando la compañía que lo desarrolla se esfuma, nuestro software continuó su evolución, bajo encargados diferentes y bajo otro nombre.

Me gusta pensar en los edificios que no son demolidos cuando la tecnología cambia, sino que nada más se adaptan. La gente no tiró casas enteras y edificios públicos cuando llegaron las computadoras en red; nada más les hicieron algunos agujeros, pusieron ductos para cables, cableado nuevo... algunos habrán terminado con sujetadores de plástico y cinta adhesiva para sostener un cable justo en su lugar, pero el edificio completo sigue ahí. La gente no demolió construcciones enteras para remplazar los excusados viejos con modelos nuevos ahorradores de agua; sólo los cambiaron — un proceso cochino y tenebroso a pequeña escala, pero completamente realizable en una tarde por un plomero con experiencia. ¡El software puede aprender de eso! Entonces, ¿cómo le hacemos para que las cosas puedan evolucionar?

En 1961, antes de que se desarrollaran las teorías de complejidad y el análisis no lineal, Jane Jacobs publicó su monumental Muerte y Vida de las Grandes Ciudades. Es un gran recorrido por los mecanismos sistémicos de las ciudades y su gente, de arquitectura y urbanismo y política e individuos. El capítulo final, llamado "Qué tipo de problema es una ciudad", tiene una explicación sumamente lúcida de la clase de herramientas mentales que necesitamos para analizar algo tan complejo como una ciudad.

Jane Jacobs escribe:

De entre los muchos cambios revolucionarios de este siglo, quizá los más profundos sean los cambios en los métodos mentales que utilizamos para evaluar el mundo. No me refiero a los nuevos cerebros mecánicos, sino a los métodos de análisis y descubrimiento que se han instalado en los cerebros humanos: nuevas estrategias del pensamiento. [...] Para comprender la conexión de estos cambios en las estrategias del pensamiento con las ciudades es necesario entender antes un poco de la historia del pensamiento científico.

Jacobs continúa, y hace un resumen de la historia del pensamiento científico, en tres etapas: primero, la habilidad para lidiar con problemas simples (ecuaciones lineales, problemas de una o dos variables, Física clásica); segundo, la habilidad para lidiar con complejidad desorganizada (teoría de probabilidad, estadística, Mecánica estadística); y tercero, la habilidad para lidiar con problemas de complejidad organizada.

Estos últimos son la clase de problemas que aparecen en los sistemas. Muchos de los métodos para abordarlos vienen de las ciencias de la vida, donde los organismos vivos son básicamente bolsas de sub-sistemas interconectados que mantienen su metabolismo de formas muy sutiles. Uno no puede sólo "resolver para una variable" y entender el sistema completo. Ocurre lo mismo con las ciudades, y a escala más pequeña con edificios individuales a lo largo del tiempo; y ocurre lo mismo con la forma en que la gente construye, interactúa con, y piensa sobre los sistemas de software.

El libro de Jane Jacobs termina con

El ser humano es difícil, y por esto cualquier tipo de asentamiento [...] tiene y plantea problemas. Las grandes ciudades tienen problemas en abundancia, pues tienen gente en abundancia. Pero las ciudades vivas no están inermes para combatir los problemas incluso maś difíciles. No son víctimas pasivas de cadenas de circunstancias, ni tampoco son el contrario maligno de la naturaleza.

Las ciudades vivas poseen maravillosas capacidades innatas para comprender, comunicar, idear e inventar lo necesario para combatir sus dificultades. [...]

Es verdad que las ciudades inertes y sin vigor suelen contener los gérmenes de su propia destrucción y poca cosa más. Pero en cambio, las ciudades de vida intensa, animada y diversa contienen las semillas de su propia regeneración y tienen la energía suficiente para asumir los problemas y necesidades ajenos.

Algunos años después del libro de Jane Jacobs, Christopher Alexander, un matemático y arquitecto, se puso a intentar matematizar el Diseño. Concretamente, él y su equipo querían averiguar por qué hay lugares construidos por humanos que son muy agradables, cómodos, buenos para vivir, y por qué hay lugares que no lo son. Los lugares agradables están presentes en todas las arquitecturas tradicionales del mundo — arquitecturas europeas, africanas, asiáticas, americanas — lo cual apuntaba a la idea de poder extraer factores comunes de todas ellas.

Al final obtuvieron una serie de patrones de arquitectura y urbanismo, que compilaron en el libro Un Lenguaje de Patrones, y mucho más tarde en un proceso adecuado para construir esos patrones, que se describe en la colección de libros titulada La Naturaleza del Orden.

Jane Jacobs encontró la narrativa de cómo funcionan las ciudades, basándose en evidencia empírica; Christopher Alexander et al encontraron las propiedades geométricas de esas ciudades y los procesos necesarios para construirlas. ¿Pero qué hay del software?

Un Lenguaje de Patrones es famoso por ser la inspiración para el libro Design Patterns. Lo que no es tan famoso es la idea, que explora Richard P. Gabriel en su libro Patterns of Software, que dice que el proceso generativo de La Naturaleza del Orden es más o menos similar a las ideas de Martin Fowler y su Refactoring. En vez de considerar la refactorización como sólo operaciones misceláneas para hacer limpieza en el código, estas ideas revalidan al proceso de refactorización como una forma de reorganizar los detalles del código a pequeña escala, para que al final sea fácil, incluso natural, el cambiar y mejorar la estructura a gran escala de un programa. Escribí un pequeño resumen de esto en mi artículo Software that has the Quality Without a Name.

Conclusión

Quiero hacer notar que el software "heredado" tiene mala reputación. Pero, ¿qué pasaría si nosotros, como desarrolladores de software, dejáramos una buena herencia en vez de una mala? ¿Qué pasaría si escribiéramos software que se puede mantener, partir en pedazos que luego se pueden unir a otros sistemas, incluso por otras personas, para que el trabajo no se pierda si decidimos o somos obligados a dejar de mantener ese software? El software libre — concretamente, el permiso explícito e irrevocable que le damos a otras personas de modificar y redistribuir nuestro software — es una precondición para que esto pueda ocurrir.

Es algo triste ver software bien amado, pero viejo y propietario, que tiene que ser encajonado en emuladores o máquinas virtuales — de hecho, sistemas de soporte vital para software moribundo y que prefiere permanecer en su entorno original. El software libre nos evita tener que poner una jaula alrededor de todo, porque podemos hacer que evolucione con todo y su entorno al mismo tiempo. Yo creo que eso es un mejor legado, una mejor herencia.

Otras lecturas

Arquitectura y Urbanismo

Jane Jacobs, Muerte y Vida de las Grandes Ciudades, Capitán Swing Libros.

No estoy al tanto de una versión en inglés que se pueda descargar de Internet. Sin embargo, como parte de la campaña "Leer la Ciudad" de activistas de urbanismo en México, hay un PDF de este libro en español disponible en ese enlace.

Aquí hay un pequeño resumen del libro en español.

Christopher Alexander et al, A Pattern Language, Oxford University Press.

Christopher Alexander et al, Un Lenguaje de Patrones, ediciones GG.

Christopher Alexander, The Nature of Order, libros 1 a 4, The Center for Environmental Structure.

Stewart Brand, How Buildings Learn, Penguin Books. Hay también una serie de TV de tres horas, en seis partes, que es maravillosa.

Nikos Salingaros, Twelve Lectures on Architecture. Un resumen de la teoría monumental de Alexander, y una matematización subsecuente. ¡Con diagramas hechos a mano!

Software

Las charlas de Katrina Owen sobre refactorización y desarrollo basado en pruebas son increíbles. Katrina empieza con un trozo de código sin documentación, o con documentación incorrecta, y sin pruebas. No hay una especificación que diga exactamente qué es lo que debería hacer el código. Y sin embargo, a través de refactorizaciones muy estándar, y con un truquito especial para poder escribir las primeras pruebas, ella logra escribir pruebas para todo el código, hacerlo legible y robusto, y convertirlo de un pequeño pantano en un jardín hermoso. El "truquito especial" consiste en asumir que si el código ya estaba funcionando (aun de forma misteriosa), puedes capturar su comportamiento actual y ponerlo como el resultado esperado de una prueba, y esto te da la pauta para empezar a refactorizar. En la plática "Therapeutic Refactoring", espera al momento en que ella dice, "... and now we have a license to go to town on this code" (ahora ya tenemos licencia para acabar con este código) cuando finalmente funcionan las pruebas — y observa una clase maestra de refactorización.

Richard P. Gabriel, Patterns of Software: Tales from the Software Community.

Federico Mena Quintero, Software that has the Quality Without A Name.