Parnas: Design for the Thing That Changes
How David Parnas’s idea of information hiding shows that every boundary in a system is a bet about what will change, and the bet is the decision.
In 1972 David Parnas asked a question that sounds trivial and is not: given a system to build, on what basis do you divide it into parts? The conventional answer was to follow the steps of the work; one module per stage of processing, the structure of the software mirroring the sequence in which it ran. Parnas built the same small system both that way and a second way, and showed that the two were identical in what they did and entirely different in what they cost to change. One could absorb a change in a single part. The other spread every change across the whole. Same behaviour, same output, opposite futures.
Parnas was a software engineer, and one of the first to insist that software should be a real engineering discipline rather than a craft. But the question he answered is not a software question, and it is why he belongs in the Deciding phase. He found the criterion for where to draw a boundary, and a boundary, as this phase has argued from several directions, is never neutral. It is a decision. Parnas tells you which decision it is.
1. Information Hiding Is Decision Hiding
Parnas’s answer to his own question was the principle he called information hiding. Each module should hide a design decision. The interface, the part other modules can see, exposes only what they need to know in order to use it. Everything else; how the work is actually done, what data structure holds it, what algorithm runs it; is secret, sealed inside the module where the rest of the system cannot reach it and, crucially, cannot come to depend on it.
The phrase is routinely misread as data hiding, the keeping-private of variables, and that misreading loses the whole idea. What a module hides is not data. It is a decision: a choice that could have gone otherwise and may one day have to be revisited. The interface is the part of the decision the rest of the system is allowed to rely on. The secret is the part the rest of the system is forbidden to rely on, so that it can change without anything else breaking.
This reframes what a system’s structure actually is. Two systems can do exactly the same thing and have completely different module boundaries, and the boundaries are the design. They determine what can change independently, what can be built in parallel, what can be understood without understanding everything else. The structure of a system is the set of decisions it has chosen to encapsulate. Build it well and each decision sits behind a boundary, changeable on its own. Build it badly and the decisions are smeared across everything, so that no decision can be revisited without revisiting all of them. Parnas made the structural fact unavoidable: every boundary hides a decision, and the quality of the system is the quality of that hiding.
2. Draw the Boundary Where the Change Will Be
If a boundary hides a decision, the obvious next question is which decisions deserve their own boundary, and Parnas’s answer is the sharp one. Draw the boundary around the decision most likely to change.
This sounds modest and is not. It means the structure of a system should be organised, not around what the system does, and not around the steps of its processing, but around a judgement about the future: which choices are volatile and which are stable. A decision that is likely to change should be sealed inside its own module, so that when the change arrives it is contained. A decision that will never change barely needs hiding at all. The whole architecture is therefore a set of bets about where change will strike, and the bets are made, consciously or not, the moment the boundaries are drawn.
This connects Parnas precisely to the rest of the phase. Simon established that complex systems must be decomposed to be tractable; Parnas supplies the criterion Simon’s account did not, the rule for where the decomposition should cut. Taleb and Christensen taught the phase to attend to volatility, to the consequential change the comfortable forecast leaves out; Parnas is the constructive answer to their warning, because designing for change means deciding, in advance, which assumptions are volatile enough to wall off. And it makes the boundary itself the thing to scrutinise. An organisation reviewing a design should not first ask what each part does. It should ask what decision each boundary is hiding, and whether that decision is one likely to change. A boundary drawn around a stable fact, or around a step of processing, is a boundary in the wrong place, and every future change will pay the bill for it.
3. The Honest Lie of the Rational Process
Parnas was too rigorous to pretend that real design proceeds cleanly. In a 1986 paper written with Paul Clements, he conceded the point most methodologies will not: no actual project ever follows a clean, rational, top-down design process. Requirements are not fully known at the start. People make mistakes. Priorities move. The real path of any design is a mess.
His response was not to abandon the rational process but to separate it from the record of the work. The documentation, he argued, should be written as if the process had been rational, even though it never was, because the person who later has to understand the system needs the rational structure, and does not need, and must not be given, a diary of the false starts. He called this faking it, and he meant the phrase without cynicism. Faking it is not dishonesty. It is the discipline of producing the clean account that makes a system comprehensible and maintainable, independently of the messy route by which it was actually reached.
There is a productive tension here with Schön, and the phase should hold both ends of it. Schön described how design really proceeds: as a reflective conversation with the situation, a thing of moves and surprises and reframings. Parnas does not deny that; he insists, on top of it, that the messy conversation must still resolve into a rational record, because the next person inherits the record, not the conversation. For an organisation deciding what to build, the lesson is exact. The deciding will be messy, and that is fine and normal. What is handed on must nonetheless be a clean, rational specification, because a specification is read by people who were not in the room, and a faithful transcript of the room’s confusion helps none of them.
4. Software Ages, and the Cause Is Ignorant Change
Parnas’s last great theme, set out in a 1994 paper, was software aging. Software, he observed, degrades over time; not through use, since it does not wear, but through change. Every modification made without regard to the system’s original structure erodes that structure a little further, and the erosion accumulates until the system can no longer be changed safely at all and must be replaced.
His name for the mechanism is exact and unkind: ignorant surgery. A change made by someone who does not understand the design, who cannot see which decision each boundary was built to hide, and who therefore cuts across the boundaries rather than respecting them. Each such change works, in the narrow sense that the system still runs. Each one also leaves the structure slightly less coherent than it found it, until the structure is gone and what remains is merely code that happens to function. The defence Parnas prescribed is documentation and discipline: keep the structure visible and intact, so that every change can be made knowingly.
This is the point at which Parnas speaks most directly to the present. AI now generates and modifies code at a scale and speed no human team can match, and by default that modification is ignorant surgery industrialised. An agent changing a system it does not understand, that cannot see which decision each boundary was protecting, will produce working code and accelerate aging at the same time. The faster the generation, the faster the structure erodes, unless the structure is deliberately documented and the boundaries deliberately enforced. AI does not change what Parnas said. It raises the cost of ignoring it, and it shortens the time you have before the bill arrives.
5. The Decision Comes First, and Always Did
Stand back and Parnas resolves into a single instruction for the Deciding phase. A module boundary is a decision. The decision is a bet about what will change. The structure of a system is the sum of those bets, and the system’s whole capacity to absorb the future is set by how well they were made. Information hiding, design for change, the faked rational record, the diagnosis of aging: four faces of one claim, that the durable value in any built thing is the quality of its decomposition, not the quantity of its code.
This is why AI, far from making design judgement less important, makes it the scarce thing. Generation is becoming nearly free; an implementation can be produced faster than it can be specified. What cannot be generated is the judgement about where the boundaries go, what each one should hide, which decisions are volatile enough to wall off. That judgement is the irreducible human contribution, and Parnas identified it half a century before the tools made it urgent. The organisation that treats AI as a way to produce more code faster will generate technical debt faster. The organisation that treats it as a reason to get deliberate about boundaries will build systems that endure. Either way the rule is the one Parnas stated in 1972: decide what to hide before you build what to show. The decision comes first. It always did.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Take one component your teams have recently built, and ask what decision each of its boundaries hides.
Choose a component, a service, or a module that was built or substantially changed in the last few months, ideally one with AI in the loop. For each boundary it has; each interface, each seam where it meets another part; ask two questions. What design decision does this boundary hide: what choice is sealed inside, free to change without breaking anything outside? And is that a decision likely to change, or is the boundary wrapped around something stable, or worse, around a step of processing? If your team can answer cleanly, the component was designed. If they cannot, it was implemented, not designed, and it is already aging. Then, before the next component is built, write down the three decisions it must encapsulate, and only then generate it. The decisions come first. That is the whole of the discipline.
Further Reading
David L. 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.
David L. Parnas and Paul C. Clements: “A Rational Design Process: How and Why to Fake It” (IEEE Transactions on Software Engineering, 1986). Why the documentation should be written as if the process had been rational, even though it never is.
David L. Parnas: “Software Aging” (Proceedings of the 16th International Conference on Software Engineering, 1994). How software degrades through change, and why ignorant surgery is the mechanism.
Daniel M. Hoffman and David M. Weiss (eds.): Software Fundamentals: Collected Papers by David L. Parnas (2001). The collected papers, with commentary. The best single entry point to Parnas’s work.
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.