In 1990, at the Universidad de Antioquia in Medellín, there was an IEEE magazine in the library whose pages had never been cut. This was not metaphor. Before the era of perfect-bound paperbacks and digital everything, some periodicals arrived folded, signatures intact, and you had to run a knife or a finger along the edge to open each section. If the pages were still sealed, it meant no one had read it. Someone had received it, shelved it, and forgotten it. The information inside was technically available and practically inaccessible — a kind of knowledge in suspension, waiting for someone to care.

My friend and mentor Mario Restrepo cared. We had been working together for a while by then — C, Pascal, the languages of that era — and he had found a reference in something else he was reading and tracked it back. He gave me the reference and told me to look it up. The article was by Grady Booch.

I did not know, at that moment, that I was holding a compass.

I. What Booch Was Arguing

What Booch was arguing in those pages — what he had been arguing for years in IEEE Software and in his early books on object-oriented design — was that software was not just a technical problem. It was a design problem. The question was not merely can this be built but should it be structured this way, and the answer required judgment, aesthetic sensibility, an understanding of what the software was for in the world beyond the machine. He drew from architecture — from Christopher Alexander and the idea of design patterns as solutions to recurring problems, from the language buildings have that programs were only beginning to develop. He insisted that the quality of software architecture was legible, that good structure could be distinguished from bad structure, and that the discipline of making that distinction was something that could be learned and taught and practiced.

This was not how software was mostly discussed in 1990. It was mostly discussed as a technical craft — you learned the language, you learned the algorithms, you made it work. The question of whether it was well made was a luxury concern, the kind of thing you worried about after the deadline. Booch said no: the structure was the thing, and getting it wrong early meant paying for it forever. The metaphor he kept returning to was architecture because architecture, unlike most engineering, produces artifacts that humans have to live inside — not just use, but inhabit.

An eighteen-year-old in Medellín, in a library in a city where the daily news was frequently catastrophic, reading an uncut magazine about software design: this is how trajectories change. Not with fanfare but with a knife along a fold.

II. The Asymmetric Relationship

Over the next three decades I read his books. Object-Oriented Analysis and Design with Applications went through editions as the field evolved, and each edition was Booch updating his thinking, not just his examples. I followed his lectures, his essays, his appearances at conferences where he spoke about software not as a product but as a civilizational project — about what it means that so much of human activity is now mediated by code written by people who have never thought carefully about what code is. I watched him become one of the voices insisting that software engineering was a discipline that needed history, philosophy, and ethics alongside its algorithms and data structures.

None of this was a relationship in any normal sense. He did not know I existed. The debt was invisible on both sides — I owed him something he did not know he had given me.

And then, years later, in a strange closing of a circle I had not known was open, I contributed to one of his projects — the Computing: The Human Experience project — in what I can only describe as a nano-scopic capacity. My name appears nowhere that matters. But I was there, in the smallest possible way, inside a project of a man whose uncut magazine had aimed my life in a direction I would not have found otherwise. The proportion between the debt and the repayment was not even worth calculating. What mattered was the closing.

III. What a Mentor Actually Is

Mario Restrepo was my first mentor in the sense that mentorship usually means: present, attentive, pointing at things in real time, telling me where to look. But the question of what a mentor is gets complicated when you try to draw the boundary cleanly. Booch mentored me through texts across a distance of thousands of miles and years of time. He didn’t know he was doing it. He was just writing carefully, thinking in public, doing the work of someone who believed that ideas matter and that articulating them clearly is itself a form of generosity.

This is what the word humanist means in a technical field, and it is rarer than it should be. The technocrat — and this is not a criticism, it is a description — solves the problem in front of them. The humanist asks what problem should be solved, and for whom, and what solving it will cost, and whether the world that results will be worth inhabiting. Booch was and is both. His technical contributions — the Booch method, the three amigos and the Unified Modeling Language, decades of writing on software architecture — are real and substantial. But what made the article in that uncut magazine grip an eighteen-year-old in Medellín was not the technique. It was the sensibility: the insistence that craft has an ethics, that structure has a responsibility, that the people who build the systems we live inside should think carefully about what they are building and why.

We need more people like him. Not more prodigies — there is no shortage of talent in this industry. We need more people who understand that knowing how to do something does not settle the question of whether to do it, and who are willing to hold both questions at once, in public, for decades, in magazines that might sit unread on library shelves until someone finally runs a knife along the edge.

Mario, thank you for handing me the knife.

Grady, I owe you more than I can calculate, and I am grateful for every year of it.

Further reading