I. The Object’s Triumph

Grady Booch is a convenient name to pin on something that happened in the 1980s and 1990s: the triumph of the object. Before that, software was process — COBOL verbs, Fortran subroutines, C functions. You described what the system does, not what it is. Programs had flows, instructions, verbs. The machine executed a sequence; you followed the sequence.

Then came the Unified Modeling Language, the design patterns, the notion that you could abstract reality into classes and hierarchies and responsibilities. The Gang of Four’s catalogue promised order: Observer, Strategy, Adapter. Each pattern was an object shape, a way of organizing code around nouns instead of verbs. Grady Booch’s Object-Oriented Analysis and Design became the grammar of a new way of thinking about computation: things that know things, things that do things, things that inherit from other things.

It worked. OOP scaled to systems large enough that you needed structure, hierarchy, a way to reason about complexity. IBM, Microsoft, Java. The object became the unit of thought.

II. The Cracks Appear

But notice what happened in the margins. As systems grew, the connections between objects became the problem. The data started living somewhere else — a relational database, another system, the network. You couldn’t hide that anymore. So we invented service-oriented architecture, then microservices. What are those? A return to processes. Systems that do things, that communicate, that have boundaries, that expose behavior instead of hiding state.

The microservices movement started as liberation — free the monolith, let each service do one thing. What followed was a distributed systems nightmare: partial failures, network latency, eventual consistency, the CAP theorem looming over every design decision. Objects had hidden complexity inside hierarchies. Microservices distributed that complexity across the network. We had traded one kind of mess for another.

III. The Other Side Never Left

Meanwhile, functional languages — Lisp, Haskell, Scheme — never abandoned the process. They insisted on functions as transformations, data as immutable, composition as the fundamental operation. For decades they looked like the losing side, the preference of academics who didn’t have real systems to ship.

Then something shifted. Go’s goroutines, Rust’s ownership model, Python’s slow drift toward immutability, JavaScript’s embrace of map and reduce — all of it signals the pendulum swinging back. The insight that immutable data and composable functions produce fewer surprises than stateful objects isn’t new; Lisp knew it in 1958. It just took fifty years of accumulated bugs to agree.

IV. The Full Arc

The data storage story tells the same history. Punch cards were pure process — instructions, verbs, sequences. Files were nouns: you could store them, move them, organize them. Relational databases tried to be both: data organized by schema and queryable by SQL, a language of processes. NoSQL swung back toward schema-less, document-oriented thinking — and then had to rebuild the query engine because nobody could live without process. GraphQL is almost pure process: you ask for what flows, not what exists.

The methodologies oscillated too. Waterfall defined the system flow, then built it. Object-oriented design promised you could specify the thing and let the flow follow. Agile argued the process is what matters — iterate, talk, deliver. DevOps took the further step: the process is the system. Your infrastructure, your deployment, your monitoring — these are the product, not the code they run.

The full arc: assembly (pure process), COBOL (process with data), C (data with function pointers), C++ (objects with data members), Java (objects as the whole story), Python (objects that act like functions), Go (functions that compose), microservices (processes that talk), serverless (processes that scale), observability (process visibility as the product).

V. What the Pendulum Is Teaching

We’re not smarter now than we were in 1985. We’re learning the lesson again.

Aristotle understood the trap two thousand years ago. His metaphysics distinguished substance — the thing, the object, the category — from activity — what the thing does, how it participates in processes larger than itself. Western philosophy spent centuries privileging substance. Things are real; processes are just things in motion. The object is the ground; the function is superstructure.

Alfred North Whitehead argued the opposite: process is primary. Reality is constituted by activity, not by static entities. Process and Reality is a difficult book, but its central claim is plain enough: objects are processes that look stable to a slow enough observer. The bank account isn’t a thing; it’s a continuous negotiation between deposits, withdrawals, interest calculations, regulatory constraints. The class called Account is a convenient fiction.

The real insight isn’t that one side is right. It’s that they’re the same question asked from opposite angles. Objects are frozen processes. Processes are objects in motion. You need both. The mistake is pretending you can pick one and win.

Grady Booch and the 1980s weren’t wrong. They just lost sight of what the objects were for — which was always to make the process clearer, more testable, more maintainable. When the object became the goal instead of the means, the pendulum started swinging back. As it always does.

The work is what matters. The models, the paradigms, the languages — they’re all trying to make the work visible. Eighty years of oscillation, and the lesson hasn’t changed: understand what you’re actually doing, and the question of how to represent it will answer itself.

The same argument, applied to automation and why calling it “AI” obscures what actually matters, is in Processes Over Objects.

Further reading

For Eduardo: forty years in tech, still trying to catch up. The pendulum owes us an apology.