David Parnas and Information Hiding: Modular Design as a Software Engineering Principle
David Parnas's 1972 information-hiding argument changed modular design from a matter of grouping related steps into a discipline of concealing decisions most likely to change.
The problem that made the idea necessary
Before Parnas, modularity was often treated as a matter of dividing a program by processing steps or functional sequence. His 1972 Communications of the ACM paper argued that the criterion used to create modules matters more than the mere existence of modules, and it compared two decompositions of the same KWIC system. [1] The historical importance of Parnas’s information-hiding approach to modular design is easier to see when the problem is framed as a maintenance and coordination problem rather than a single feature. The change altered what engineers could treat as a stable assumption and what had to remain open to revision.
The KWIC comparison made change costs visible
The two KWIC decompositions delivered the same user-visible function, so the difference appeared only when a design decision changed. That made maintenance cost, not output correctness, the decisive measure of architectural quality. This detail made the abstract principle concrete enough for practitioners to compare alternatives instead of treating architecture as personal taste.
The central design move
The alternative decomposition assigned each module a design decision that other modules were not allowed to know. Data representation, algorithm choice, device assumptions and file organization could become module secrets so that likely future changes remained localized behind an interface. [2] The proposal was powerful because it changed the unit of reasoning. Instead of asking only whether code worked today, engineers could ask which decisions should be isolated, automated, standardized or made explicit so that future changes would be cheaper and safer.
A module secret is not security through obscurity
Information hiding does not mean hiding source code from attackers. The hidden information is an implementation decision that clients do not need in order to use a module correctly. The distinction matters because many later misunderstandings came from copying the surface form while missing the reason the technique was introduced.
How the mechanism worked in practice
This idea made stable interfaces central. A client should depend on the operations and properties it needs while remaining ignorant of internal tables, algorithms or storage layouts. Parnas later connected this style to software that can be extended and contracted with less widespread modification. [3] In practical engineering, a method survives only when ordinary developers can use it repeatedly. The key mechanisms therefore became conventions, interfaces and tools that could be applied during everyday development rather than reserved for rare design reviews.
Interfaces became durable engineering contracts
When callers depend only on a documented interface, maintainers can optimize or replace the implementation without coordinating edits across every client. This is the foundation of long-lived libraries and services. Once the mechanism was repeatable, it could be embedded in team conventions and tooling, which is how a research or design idea becomes everyday infrastructure.
The milestone that made the approach visible
Parnas and Paul Clements also argued that documentation should present requirements, interfaces and design decisions coherently even though real development is rarely a perfectly rational sequence. The goal was to leave maintainers a usable model of what may change and what other components are entitled to assume. [4] A historical milestone matters when it turns an idea into something a larger community can trust. Publication, self-hosting, standardization, a major release or institutional adoption made the approach visible enough for other teams to copy and challenge.
Documentation preserves design intent
Maintainers need to understand why a boundary exists and which assumption it protects. Good design documentation therefore records rationale and contracts, not merely a chronological diary of coding activity. The milestone also produced evidence that the technique could survive contact with real projects, users and organizational constraints rather than remaining a paper design.
The engineering consequences
Information hiding reduces coupling by reducing shared knowledge. Two modules can be tightly coupled even with few direct calls if both rely on the same representation detail. Assigning one owner to a volatile decision prevents that hidden dependency from spreading throughout the system. [5] The consequence was not simply better code in one project. The approach influenced how teams divided responsibility, reviewed work, preserved evidence and planned change, making the development process itself more inspectable and repeatable.
The tradeoffs and limits
The principle supports program families and product variation because implementation choices can be swapped behind stable boundaries. Later component systems, abstract data types, packages, plug-ins and service APIs all reuse the same basic strategy of separating what clients need from how a service is implemented. [1] Every engineering practice creates costs as well as benefits. The useful historical question is not whether the method is universally correct, but which failure modes it reduces and which new complexity, bureaucracy or maintenance burden it can introduce.
How the idea evolved
Parnas later wrote about software aging, arguing that systems deteriorate as environments change and modifications damage structure. Information hiding cannot prevent all aging, but well-chosen boundaries make it easier to replace obsolete decisions without destabilizing unrelated code. [2] Later tools and methods often absorbed the original idea until it became less visible. That is a sign of influence: what began as an explicit technique can become a default feature of languages, IDEs, platforms, governance or release infrastructure.
Why this belongs in CodeHistory
The lasting importance of information hiding is that it reframed modularity as a strategy for managing change. Encapsulation, interface segregation and implementation independence use different vocabulary, but all reflect the same insight that software becomes maintainable when likely change is confined behind stable contracts. [3] The enduring lesson is that software engineering is largely the engineering of change. Tools and practices become historically important when they let many people modify a system with less uncertainty, smaller blast radius and clearer shared expectations.
Works Cited
- 01
- 02
- 03
- 04D. L. Parnas — Software Aging doi.org
- 05McMaster Experts — David Parnas Scholarly Work experts.mcmaster.ca
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead