This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
In this episode, Alistair Cockburn and host Eberhard Wolff discussed fundamental principles of software modularization that remain surprisingly relevant decades after their initial formulation. Their conversation centered on David Parnas’s groundbreaking 1972 paper on decomposing systems into modules — a work that continues to define how we design software today.
The Core Insight: Decisions, Not Data
The discussion revealed a subtle but crucial distinction that often gets lost in translation. While Parnas’s work is frequently cited as being about “information hiding,” Cockburn emphasizes that the real focus is decision hiding. As Parnas himself wrote in his conclusion: “Each module is then designed to hide such a decision from the others.”
This distinction matters profoundly. When we expose instance variables in a class, we’re not just exposing data — we’re exposing a design decision about how that data is stored or calculated. If a client accesses an account balance directly, we can never change whether that balance is stored or computed on demand. Similarly, when application code directly accesses database queries, it locks in technological decisions that become increasingly difficult to change.
From Theory to Practice
Cockburn illustrated how these principles manifest in modern architectures. Hexagonal architecture fundamentally addresses the same challenge: hiding the decision about which technologies to use. The example of database access proves particularly relevant —many teams embed SQL directly throughout their codebase, making it nearly impossible to migrate technologies later.
Interestingly, Cockburn notes that these principles have already been successfully encoded into standard libraries. When developers use collections or output methods, they benefit from encapsulation without thinking about it—progress made possible by the intense discussions of the 1990s.
Beyond Technical Decisions
The conversation evolved to address modularization in business logic through event storming and bounded contexts. By identifying pivotal events where the world changes and swim lanes with parallel activities with minimal communication, teams can derive natural module boundaries from the workflow.
Lessons for Today
The exchange between Cockburn and Wolff highlights an enduring tension in software design: the push between simplicity and generalization. YAGNI — “You Ain’t Gonna Need It” — emerged in the 1990s precisely because teams were creating overly generic systems with too many “hinge points.” Yet completely dismissing change scenarios can be equally problematic.
Conclusion
After fifty years, Parnas’s insights remain profound: good modularization requires identifying which design decisions are likely to change, then carefully hiding those decisions within module boundaries. Whether addressing technology choices, data storage approaches, or domain logic, the principle holds: reduce the trajectory of change by isolating decisions. Modern practitioners don’t need new theories—they need to apply proven wisdom with appropriate judgment, knowing when to plan for flexibility and when to keep things simple.