En 1990, en la Universidad de Antioquia en Medellín, había una revista IEEE en la biblioteca cuyas páginas nunca habían sido cortadas. No es metáfora. Antes de la era del libro de bolsillo y de todo lo digital, algunas publicaciones llegaban dobladas, con los cuadernillos intactos, y había que pasar un cuchillo o un dedo por el pliegue para abrir cada sección. Si las páginas seguían selladas, significaba que nadie la había leído. Alguien la había recibido, la había archivado y se había olvidado de ella. La información adentro era técnicamente disponible y prácticamente inaccesible — un conocimiento en suspenso, esperando que alguien se preocupara por él.

Mi amigo y mentor Mario Restrepo se preocupó. Para entonces ya llevábamos un tiempo trabajando juntos — C, Pascal, los lenguajes de esa época — y había encontrado una referencia en otra lectura y la había rastreado hasta aquí. Me dio la referencia y me dijo que lo buscara. El artículo era de Grady Booch.

No sabía, en ese momento, que tenía una brújula en las manos.

I. Lo que Booch argumentaba

Lo que Booch argumentaba en esas páginas — lo que había argumentado durante años en IEEE Software y en sus primeros libros sobre diseño orientado a objetos — era que el software no era solo un problema técnico. Era un problema de diseño. La pregunta no era meramente ¿puede construirse esto? sino ¿debería estructurarse así?, y responderla requería juicio, sensibilidad estética, comprensión de para qué servía el software más allá de la máquina. Se apoyaba en la arquitectura — en Christopher Alexander y la idea de los patrones de diseño como soluciones a problemas recurrentes, en el lenguaje que tienen los edificios y que los programas apenas empezaban a desarrollar. Insistía en que la calidad de la arquitectura de software era legible, que la buena estructura podía distinguirse de la mala, y que la disciplina de hacer esa distinción era algo que podía aprenderse, enseñarse y practicarse.

Esto no era cómo se hablaba del software en 1990, al menos no mayoritariamente. Se hablaba de él como un oficio técnico: aprendías el lenguaje, aprendías los algoritmos, lo hacías funcionar. La pregunta de si estaba bien hecho era un lujo, algo que te preguntabas después del plazo de entrega. Booch decía que no: la estructura era lo fundamental, y equivocarse en ella temprano significaba pagar por eso para siempre. La metáfora a la que volvía era la arquitectura porque la arquitectura, a diferencia de la mayoría de las ingenierías, produce artefactos en los que los humanos tienen que vivir — no solo usar, sino habitar.

Un joven de dieciocho años en Medellín, en una biblioteca de una ciudad cuyas noticias cotidianas eran con frecuencia catastróficas, leyendo una revista sin cortar sobre diseño de software: así cambian las trayectorias. No con fanfarria sino con un cuchillo a lo largo de un pliegue.

II. La relación asimétrica

Durante las tres décadas siguientes leí sus libros. Object-Oriented Analysis and Design with Applications pasó por varias ediciones a medida que el campo evolucionaba, y cada edición era Booch actualizando su pensamiento, no solo sus ejemplos. Seguí sus conferencias, sus ensayos, sus apariciones en congresos donde hablaba del software no como un producto sino como un proyecto civilizatorio — sobre lo que significa que tanta actividad humana esté ahora mediada por código escrito por personas que nunca han pensado con cuidado qué es el código. Lo vi convertirse en una de las voces que insistían en que la ingeniería de software era una disciplina que necesitaba historia, filosofía y ética junto a sus algoritmos y estructuras de datos.

Nada de esto era una relación en ningún sentido normal. Él no sabía que yo existía. La deuda era invisible por ambos lados — le debía algo que él no sabía que me había dado.

Y entonces, años después, en un cierre extraño de un círculo que yo no sabía que estaba abierto, contribuí a uno de sus proyectos — el proyecto Computing: The Human Experience — en lo que solo puedo describir como una capacidad nano-scópica. Mi nombre no aparece en ningún lugar que importe. Pero estuve allí, de la manera más pequeña posible, dentro de un proyecto del hombre cuya revista sin cortar había apuntado mi vida en una dirección que de otro modo no habría encontrado. La proporción entre la deuda y el pago no valía ni calcularse. Lo que importaba era el cierre.

III. Lo que un mentor realmente es

Mario Restrepo fue mi primer mentor en el sentido que la mentoría suele significar: presente, atento, señalando cosas en tiempo real, diciéndome dónde mirar. Pero la pregunta de qué es un mentor se complica cuando intentas trazar la frontera con claridad. Booch me mentorizó a través de textos, a una distancia de miles de kilómetros y años de tiempo. No sabía que lo estaba haciendo. Simplemente escribía con cuidado, pensaba en público, hacía el trabajo de alguien que creía que las ideas importan y que articularlas con claridad es en sí misma una forma de generosidad.

Esto es lo que la palabra humanista significa en un campo técnico, y es más raro de lo que debería ser. El tecnócrata — y esto no es una crítica, es una descripción — resuelve el problema que tiene enfrente. El humanista pregunta qué problema debería resolverse, y para quién, y qué costará resolverlo, y si el mundo que resulte valdrá la pena habitarlo. Booch fue y es ambas cosas. Sus contribuciones técnicas — el método Booch, los tres amigos y el Lenguaje Unificado de Modelado, décadas de escritura sobre arquitectura de software — son reales y sustanciales. Pero lo que hizo que el artículo en esa revista sin cortar atrapara a un joven de dieciocho años en Medellín no fue la técnica. Fue la sensibilidad: la insistencia en que el oficio tiene una ética, que la estructura tiene una responsabilidad, que las personas que construyen los sistemas en los que vivimos deberían pensar con cuidado qué están construyendo y por qué.

Necesitamos más personas como él. No más prodigios — no hay escasez de talento en esta industria. Necesitamos más personas que entiendan que saber cómo hacer algo no resuelve la pregunta de si hacerlo, y que estén dispuestas a sostener ambas preguntas a la vez, en público, durante décadas, en revistas que quizás permanezcan sin leer en estantes de biblioteca hasta que alguien finalmente pase un cuchillo por el pliegue.

Mario, gracias por pasarme el cuchillo.

Grady, te debo más de lo que puedo calcular, y estoy agradecido por cada año de ello.

Lecturas adicionales