Every Boundary Is a Decision: A Brief History of Object Oriented Design
Six decades of software design proved that the hard problem was never the code.
A practitioner I spoke with described a recent architecture review. The team had used AI to generate a working service in two days. The code compiled. The tests passed. The demo was impressive. Then someone asked where the service boundary was, why it was there, and what it was hiding from the rest of the system. Silence. The AI had written the code. Nobody had made the design decisions.
This is the story of AI-augmented development in many enterprises right now. The implementation is fast. Some decisions are absent. And the decisions are all that matter, because every module boundary, every interface, every contract between components is a choice about what to reveal, what to hide, what to promise, and what to defer. The object-oriented design tradition spent six decades proving this. Their conclusion is the Deciding phase hypothesis arrived at from the opposite direction:
Design is a sequence of decisions under constraint, and no amount of generated code changes what the decisions are or who must make them.
1. The Simulation Premise: Describing the World in Code
The story begins in Norway in the early 1960s. Ole-Johan Dahl and Kristen Nygaard, working at the Norwegian Computing Center, needed to simulate complex systems with concurrent processes. Their solution was Simula, the language that introduced classes, objects, inheritance, and virtual procedures. The concepts were not invented as programming conveniences. They were invented as modelling necessities. Nygaard’s insight was that the concepts needed to describe a system should be the concepts used to program its simulation.
This was a radical philosophical wager: that the structure of software could mirror the structure of reality. An object in the programme corresponded to an entity in the world. A class described a kind of thing. Inheritance expressed the relationship between kinds. The simulation was not a metaphor for the system; it was a description of it.
Every subsequent object-oriented thinker inherited this wager and progressively qualified it. The history of OO design is a history of deepening scepticism about what software can and cannot describe, and under what conditions. Each generation added a constraint. The accumulation of constraints is what turned a programming paradigm into a decision discipline. And the constraints map, with uncomfortable precision, onto the problems this series has been diagnosing from the organisational side.
2. Messaging and Autonomy: Kay’s Biological Metaphor
Alan Kay, working at Xerox PARC in the 1970s, took Dahl and Nygaard’s objects and reimagined them through a biological lens. Objects were not data structures. They were autonomous agents, like cells, each containing its own state and process, communicating only through messages. The sender could not know or control what happened inside the receiver. Kay later said he regretted coining the term “objects” because it focused attention on the lesser idea. The big idea was messaging.
This matters for decisions because messaging creates genuine autonomy. If objects interact only through messages, then each object’s internal decisions are hidden from every other. The system’s behaviour emerges from the pattern of messages, not from any central plan. Kay was describing, in software, what Beer would recognise as a viable system: autonomous units coordinating through defined channels, each managing its own variety internally.
Kay’s wager was that the messaging metaphor could describe any system because it mirrors how complex systems actually work. Not representation (objects look like things) but interaction (objects communicate like organisms). The organisational parallel is immediate: the question is not what your teams contain but how they communicate, and whether the communication channels create autonomy or dependency. Conway formalised this. Kay built the programming model that makes it visible.
3. The Secret Inside the Module: Parnas and Information Hiding
David Parnas, writing in 1972, asked a question that seems simple and is not: on what criteria should you decompose a system into modules? The conventional answer was to follow the processing steps. Parnas’s answer was different: each module should hide a design decision. The interface reveals what other modules need to know. Everything else is secret.
This is not just data hiding. It is decision hiding. The question is not “what data does this module store?” but “what decision does this module encapsulate?” Two systems can be identical in runtime behaviour and radically different in modular structure. The modular structure determines what can change independently, what can be developed in parallel, and what can be understood without understanding everything else.
Parnas’s insight connects directly to Simon. Simon argued that complex systems must be nearly decomposable to be manageable: strong interactions within modules, weak interactions between them. Parnas provides the criterion for where to draw the boundaries: at design decisions that are likely to change. Evans operationalises the same principle at the domain level: each bounded context hides its domain model behind a boundary, and what crosses the boundary is the contract, not the model.
For AI transformation, Parnas’s insight is the one that bites hardest. AI can generate implementations with extraordinary speed. It cannot decide what to hide. Every module boundary is a judgment about what will change, what should be isolated, and what other teams need to know.
That judgment SHOULD be the human contribution, and no amount of generated code substitutes for the judgement of the appropriate service boundaries.
4. The Abstraction Guarantee: Liskov and Substitutability
Barbara Liskov, one of the first women to earn a PhD in computer science in the United States, spent decades at MIT formalising what it means for one component to be safely substitutable for another. Her Liskov Substitution Principle (1987) states that if S is a subtype of T, then objects of type T can be replaced with objects of type S without altering the correctness of the programme. This is not a syntactic rule. It is a semantic guarantee: the replacement must honour the original’s behavioural contract.
Liskov added a constraint the earlier thinkers lacked: the history constraint. The pattern of state changes in a subtype must be consistent with the supertype’s possible histories. You cannot simply match the interface. You must match the behaviour over time. This is the most rigorous position in the OO tradition: world-description through provable correctness.
The organisational parallel is the promise that teams make to each other. When one team replaces a service, the consuming teams should not break. That requires not just interface compatibility but behavioural compatibility: the new service must honour the same contracts under the same conditions over the same time horizons. Liskov showed that this guarantee is not a matter of goodwill. It is a matter of formal discipline. Without it, every substitution is a gamble.
5. Making the Rules Explicit: Meyer’s Design by Contract
Bertrand Meyer, working independently from Liskov, arrived at the same formal structure from a different direction. His Design by Contract (1986) uses a business metaphor: software components interact like parties bound by a contract. Every interaction has preconditions (what the caller must provide), postconditions (what the supplier guarantees), and invariants (what must always hold). Contracts are not documentation. They are executable, checkable specifications embedded in the code.
Meyer’s position is Popperian: a correct programme is one whose claims about its own behaviour are falsifiable and have not been falsified. The contract defines the boundary of correct behaviour. Code outside this space is by definition defective. This connects to Argyris more directly than any other OO thinker. Argyris showed that the governing variables controlling organisational behaviour are invisible until someone makes them explicit. Meyer showed the same thing in software: the assumptions governing component interaction are invisible until they are formalised as contracts. In both cases, making the implicit explicit is the precondition for change.
Meyer acknowledged that not all contracts can be fully formalised. Some aspects of what a component should do can only be stated in natural language. But the aspiration is to formalise as much as possible, because every formalised constraint is one fewer hidden assumption waiting to fail in production.
6. Responsibility Before Structure: Wirfs-Brock’s Behavioural Turn
Rebecca Wirfs-Brock inverted the conventional approach to object design. Before her 1989 OOPSLA paper, the dominant method was data-driven: identify the entities, define their attributes, then add behaviour. This was entity-relationship modelling dressed in object-oriented syntax, and it produced static, anaemic systems. Wirfs-Brock started from the other end: what is this object responsible for? What does it do, not what does it contain?
Her metaphor was explicitly organisational. A software system is like a community. Each object has a role, duties, and collaborators. Design is the process of assigning responsibilities to the right objects and defining the collaborations between them. The pattern of collaboration, who talks to whom about what, defines the architecture.
Beer would recognise this instantly: the viable system is defined not by its components but by the relationships between them. Conway would add that the collaboration pattern will mirror the communication structure of the team that built it. Wirfs-Brock showed that the same principle operates inside the software: the system’s architecture is its collaboration structure, and designing the collaboration is the real design problem.
7. The Trajectory of Scepticism
Grady Booch, whose textbook defined OO analysis and design for a generation, framed the entire tradition as a response to complexity. The object model (abstraction, encapsulation, modularity, hierarchy) exists not because it mirrors the world but because it mirrors how the human mind manages what it cannot hold all at once. This is Simon’s bounded rationality applied to software: no one can hold the whole system in their head, so the decomposition strategy is the design.
The trajectory from Dahl and Nygaard to Evans (already covered in this series) is a trajectory of deepening scepticism. Each generation said: you can describe the world in software, BUT only through messages (Kay), BUT only by hiding what changes (Parnas), BUT only with behavioural guarantees (Liskov), BUT only with explicit contracts (Meyer), BUT only through responsibility-based collaboration (Wirfs-Brock), BUT only by managing complexity hierarchically (Booch), BUT only within bounded contexts with ubiquitous language (Evans). The accumulation of “buts” is the discipline’s intellectual maturation.
Every one of these constraints is a decision. What to hide. What to promise. Where to draw boundaries. How to allocate responsibility. Which aspects of the world to describe and which to deliberately ignore. The OO tradition proved empirically what Simon theorised: design is not implementation. It is the sequence of decisions that determines what the implementation can be. AI can now handle the implementation at extraordinary speed. The decisions remain exactly as hard as they were in 1972, when Parnas first showed that the criteria for decomposition were more important than the decomposition itself.
8. What This Means for Your AI Transformation
Every thinker reviewed here was solving an organisational problem disguised as a technical one. Dahl and Nygaard asked: how do teams communicate about systems? Kay asked: how do autonomous agents coordinate? Parnas asked: how do teams work independently? Liskov asked: how do you guarantee that replacing one component with another will not break the system? Meyer asked: how do you make the rules of collaboration explicit? Wirfs-Brock asked: how do you design a system as a community? Booch asked: how do you keep the whole thing comprehensible?
These are not software questions. They are the questions this entire series has been asking from the organisational side. The convergence is not a coincidence. It is evidence that the Deciding phase hypothesis is correct: decisions are design challenges, and design is a sequence of decisions under constraint. The software tradition and the management tradition arrived at the same conclusion independently, over the same decades, from opposite directions.
AI-generated code does not change this. It accelerates implementation. It does not accelerate the judgment about what to implement, where to draw the boundaries, what to hide, and what to promise. The organisation that treats AI as an implementation accelerator while investing in the decision discipline will build systems that endure. The organisation that treats AI as a substitute for design decisions will generate code faster than it has ever generated technical debt.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Ask “what is this module hiding?” before you ask “what does this module do?”
Take one AI-generated component your team has recently built. Identify the design decisions embedded in it: where are the boundaries? What information is hidden behind each interface? What contract does each interface promise to its consumers? If your team cannot answer these questions, the component is not designed; it is merely implemented. Before generating the next component, write down the three decisions it must encapsulate. Then generate. The decisions come first. They always did.
Further Reading
David Parnas: On the Criteria To Be Used in Decomposing Systems into Modules (Communications of the ACM, 1972). The foundational paper on information hiding. Twelve pages that changed how software systems are structured. Freely available.
Bertrand Meyer: Object-Oriented Software Construction - The definitive statement of Design by Contract and the most rigorous treatment of what correctness means in object-oriented systems.
Rebecca Wirfs-Brock and Alan McKean: Object Design: Roles, Responsibilities, and Collaborations - Responsibility-driven design as an alternative to data-driven modelling. The organisational metaphor applied to software.
Grady Booch: Object-Oriented Analysis and Design with Applications - The standard textbook. The complexity argument and the four fundamentals of the object model.
Alan Kay: The Early History of Smalltalk - Kay’s own account of how objects, messaging, and the Dynabook vision emerged. Freely available.
I write about the industry and its approach in general. None of the opinions or examples in my articles necessarily relate to present or past employers. I draw on conversations with many practitioners and all views are my own.