Christopher Alexander: un lenguaje para lo que no tiene nombre

Casi cualquier persona que programe hoy usa la palabra patrón varias veces al día. Un Singleton, un Observer, un Factory: piezas de vocabulario que se aprenden pronto y se dan por evidentes, como si hubieran existido siempre. Yo mismo aprobé más de una entrevista técnica donde puntuabas por cuántos de esos nombres eras capaz de soltar, vinieran o no a cuento: se medía la fluidez con el catálogo, nunca el juicio. Ahora que la IA escupe ese catálogo sola, parece que de golpe todos nos hemos vuelto a acordar del juicio.

Casi nadie recuerda que todo ese repertorio desciende de un libro que no hablaba de software, sino de pueblos, calles y del sitio exacto donde conviene poner un asiento junto a una ventana. Y casi nadie sabe que su autor, al final de su vida, miró lo que la informática había hecho con su idea y no supo si sentirse orgulloso o traicionado.

Ese autor es Christopher Alexander. Merece la pena volver a él no para reclamar una genealogía curiosa, sino porque en su obra late una pregunta que seguimos sin responder: ¿de dónde viene la calidad de las cosas bien hechas, y por qué se nos escapa en cuanto intentamos sistematizarla?

Contra el planificador

Alexander (Viena, 1936 - California, 2022) llegó a la arquitectura desde las matemáticas y la química, con un doctorado en Harvard que dio lugar a su primer libro, Notes on the Synthesis of Form (1964). Enseñó casi toda su vida en Berkeley. Escribía, por tanto, desde dentro de una disciplina, pero con la mirada de quien había aprendido a formalizar problemas antes de aprender a levantar muros.

Lo que le indignaba era el modo dominante de construir en el siglo XX: el urbanismo del plan maestro, la arquitectura del Estilo Internacional, la ciudad concebida como un objeto que un especialista dibuja entero sobre el papel y luego impone sobre el terreno. Ese modelo, sostenía, produce entornos muertos. No porque los arquitectos fueran malos, sino porque el diseño se había convertido en monopolio de expertos que trabajaban sin un vocabulario común y sin la participación de quienes iban a habitar el resultado.

Su respuesta no fue proponer un estilo mejor, sino desplazar el problema. La calidad, decía, no es una propiedad del genio individual: es una propiedad del lenguaje con el que se diseña. Ahí empieza todo lo interesante.

El patrón como unidad de conocimiento

La pieza básica de su sistema es el patrón. No una plantilla ni una receta, sino la descripción de un problema que se repite junto con el núcleo de su solución.

Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y describe después el núcleo de la solución a ese problema, de tal modo que puedes usar esa solución un millón de veces sin hacerla nunca dos veces igual.

— A Pattern Language (1977)

La última cláusula es la que la mayoría olvida y la que lo cambia todo. Un patrón no es un componente que se copia y se pega. Es una relación estable entre un problema, un contexto y una resolución, que cada vez se encarna de forma distinta. "Asiento junto a la ventana" no dice qué madera, ni qué medidas, ni qué vistas; dice que las personas gravitan hacia la luz cuando se sientan, y que conviene diseñar para esa gravitación. Lo invariante es la tensión que se resuelve, no la forma que la resuelve.

Es exactamente la distinción que el software tardó décadas en aprender y que sigue confundiendo. Un patrón de diseño no es una biblioteca ni un framework: es una manera de pensar un problema recurrente. Cuando lo tratamos como código que se pega, lo matamos.

Un lenguaje, no un catálogo

El salto de Alexander no fue reunir soluciones, sino descubrir que se conectan. Sus 253 patrones —de la escala de las regiones a la de un tirador de puerta— forman una red: invocar uno activa los contiguos. Un lenguaje, y no una lista, porque de un vocabulario finito se generan combinaciones infinitas y coherentes, igual que de unas pocas reglas gramaticales sale una conversación que nadie había tenido antes.

Esa palabra, lenguaje, carga con toda su ambición política. Si el diseño es un lenguaje, entonces puede compartirse, y si puede compartirse, deja de ser monopolio del especialista. Alexander quería devolver a la gente corriente la capacidad de dar forma a su propio entorno: que un vecino pudiera participar en cómo se construye su calle con la misma legitimidad que el arquitecto, porque ambos hablarían el mismo idioma de problemas y soluciones.

Es una intuición que resuena con otra tradición que he tratado aquí, la de la catedral y el bazar: la sospecha de que los mejores conjuntos no salen de un único plano cerrado, sino de muchas manos que aportan piezas pequeñas hablando un vocabulario común. No es casualidad que fuera precisamente la comunidad del software libre la que abrazara a Alexander. Ward Cunningham inventó el wiki —la primera web editable por cualquiera— con el propósito explícito de alojar un lenguaje de patrones. La herramienta que hizo posible la Wikipedia nació para catalogar problemas recurrentes de programación al modo de un arquitecto.

Crecimiento por piezas

De ahí se sigue una idea sobre el tiempo. Un pueblo con vida no se termina: crece por piezas, corrige, añade, se repara a sí mismo. Alexander la llamaba piecemeal growth, y la oponía al plan maestro que lo decide todo de antemano y no admite enmienda. El orden no se impone desde fuera; emerge desde dentro, decisión a decisión, siempre que cada decisión respete el conjunto.

No se quedó en la teoría. En The Oregon Experiment (1975) llevó estas ideas a un caso real: el plan de la Universidad de Oregón, diseñado no por un despacho externo sino por su propia comunidad —estudiantes, profesores, personal— usando un lenguaje de patrones común, construyendo poco a poco y reparando sobre la marcha en lugar de ejecutar un plano cerrado. El campus como bazar, no como catedral.

Cuesta no oír aquí, con cuarenta años de antelación, buena parte de lo que luego llamaríamos desarrollo iterativo. Quien dirige producto digital vive de esto: el producto no se proyecta entero y se entrega acabado, sino que se descubre construyéndolo. Es, en el fondo, la misma tensión entre rigidez y flexibilidad que aparece cuando uno se pregunta dónde encajan de verdad las organizaciones de producto digital, herederas a la vez del plano industrial y del bazar que lo contradice.

La calidad sin nombre

Y sin embargo, por debajo de los patrones, del lenguaje y del crecimiento, Alexander perseguía algo que él mismo reconocía indecible. Lo llamó, con una honestidad que roza lo místico, the quality without a name.

Hay una cualidad central que es el criterio raíz de la vida y el espíritu en un hombre, un pueblo, un edificio o un paraje silvestre. Esta cualidad es objetiva y precisa, pero no puede nombrarse.

— The Timeless Way of Building (1979)

Objetiva y precisa, pero innombrable. Ahí está toda la tensión de su obra, y quizá toda la tensión de nuestro oficio. Alexander dedicó su vida a construir un método —un lenguaje, un catálogo, un sistema— para producir algo que su propio método no podía capturar del todo. Los patrones eran andamios hacia una cualidad que los excedía.

Cualquiera que haga producto reconoce esa cualidad sin nombre. Es la diferencia entre una función que cumple la especificación y otra que, cumpliéndola igual, está viva: se siente correcta, encaja, respira. No hay métrica que la mida ni ticket que la describa. Y como el software desvanece una y otra vez nuestras aspiraciones de control integral sobre el resultado, esa cualidad se nos escapa justo cuando más creemos tenerla dominada. Alexander nombró el problema mucho antes de que tuviéramos pantallas: se puede sistematizar el camino hacia la calidad, pero no la calidad misma.

Dónde se queda corta

Sería fácil convertir a Alexander en oráculo, y él sería el primero en desconfiar. Su idea tiene grietas que importan.

La primera es de fondo. Un lenguaje de patrones supone que los problemas se repiten de forma lo bastante estable como para codificarse. Eso vale para un asiento junto a una ventana, que responde a un cuerpo humano que apenas cambia en milenios. Pero en producto digital el propio espacio del problema se mueve mientras lo trabajamos: lo que ayer era un patrón sólido hoy es deuda. Los patrones describen respuestas que funcionaron en el pasado; dicen poco cuando la pregunta misma está cambiando, que es la condición normal de lo digital. El propio Alexander lo concedió a su manera en su obra tardía, The Nature of Order, donde el lenguaje de patrones se le quedó pequeño.

La segunda es una contradicción interna. El libro promete democratizar el diseño, pero los 253 patrones los eligieron Alexander y sus colaboradores. El lenguaje "compartido" se redactó de arriba abajo y se entregó luego a las comunidades como si emergiera de ellas. La participación es real, pero ocurre dentro de un vocabulario que otro escogió. Todo el que ha impuesto un design system en una organización y lo ha llamado "lenguaje común" conoce esa incomodidad.

La tercera la puso el propio Alexander. En 1996 lo invitaron a dar la conferencia de apertura del principal congreso de programación orientada a objetos, ante la comunidad que lo había convertido en santo patrón. En lugar de celebrar, preguntó si los patrones de software mejoraban de verdad la vida de las personas, o si solo hacían el código más limpio. Sospechaba que la informática había tomado la mecánica de su idea y había dejado fuera su alma moral. Se marchó sin la respuesta.

Por qué importa hoy

Despojada de misticismo, la lección de Alexander para quien dirige producto es organizativa antes que estética: la calidad del diseño escala solo cuando el equipo comparte un vocabulario de trabajo para los problemas que se repiten. Cuando ese vocabulario no existe, la calidad vive únicamente en la cabeza de unas pocas personas que han monopolizado el criterio, y eso explica el fenómeno que todos hemos visto: el diseñador o el ingeniero senior que toma buenas decisiones una tras otra y no sabe enseñar a nadie a replicarlas, porque no las tiene formuladas como lenguaje, sino como intuición.

Los design systems, las bibliotecas de componentes, los catálogos de patrones de interacción son intentos —a menudo pobres— de tener ese lenguaje. Pobres porque solemos quedarnos en la capa que Alexander despreciaba: la forma reutilizable, el componente que se pega, en vez de la relación entre problema y contexto que le daba sentido. Nos llevamos el asiento y olvidamos la luz.

Su idea desafía además una costumbre muy asentada: la de separar el descubrimiento de la construcción en fases sucesivas. Un patrón codifica a la vez el problema y su solución, la pregunta y la respuesta como una sola cosa. Eso se parece mucho más a cómo piensan de verdad los buenos directores de producto que cualquier modelo de etapas cerradas. La pregunta que su libro nos obliga a hacernos es incómoda y sencilla: ¿tiene mi organización un lenguaje de patrones, o la calidad vive solo en unas pocas cabezas?

Lo que sigue sin nombre

Volvamos al principio. Cada vez que un equipo nombra un Singleton o un Observer está usando, sin saberlo, el vocabulario de un arquitecto que quería que la gente corriente recuperase su casa. La idea viajó, se hizo inmensamente útil y, por el camino, perdió parte de lo que la animaba. Nos quedamos con el catálogo y soltamos la cualidad sin nombre.

Quizá esa pérdida no sea un accidente, sino la naturaleza misma del asunto. Se puede compartir un lenguaje; no se puede compartir el juicio que decide, en cada caso concreto, cuándo una solución está viva y cuándo solo es correcta. Alexander pasó una vida entera construyendo el mejor andamio posible hacia algo que el andamio no alcanza. No es un fracaso: es, probablemente, la forma más honesta de trabajar sobre lo que importa. La pregunta que nos deja no es cómo catalogar mejor, sino cómo no confundir nunca el catálogo con la cosa.