Parnas: Designed to Be Deleted
David Parnas returns, and the property nobody designs for is the one that decides whether your system can still be changed.
Ask a team to add a feature and you will get an estimate. Ask the same team to remove one and watch what happens. There is a pause, then a set of questions nobody can answer: what else calls it, what would break, whether anyone still uses the reporting job that reads its table. The estimate, when it eventually comes, is larger than the estimate for building it in the first place. Everybody accepts this as the natural order of things, and I have never once heard it questioned in a planning session.
Parnas did not. In March 1979 he published a paper in IEEE Transactions on Software Engineering whose title contains the word almost nobody carried forward: “Designing Software for Ease of Extension and Contraction”. The industry took the extension half, built a fifty-year practice on it, and quietly dropped the other. Deciding used Parnas for information hiding and for where to draw a boundary. Building needs the half nobody read, because a system you cannot subtract from is a system you have stopped being able to change, and free generation is producing those at a rate no organisation has previously managed.
1. You are not building a program
Three years before the contraction paper, Parnas published a shorter one with a claim that still sounds strange: you are never designing a program. You are designing a family of programs, and the one you happen to ship is a member of it.
The reasoning is unsentimental. Any system that survives will exist in variants: an early release with less in it, a customer-specific version, a stripped build for a constrained environment, next year’s edition without the module that regulation killed. Those variants exist whether or not you designed for them. If you did not, each one is produced by mutilation, and the mutilations accumulate.
Designing the family means making the decisions common to all members first and holding them stable, then isolating the decisions that distinguish one member from another so they can be changed without disturbing the rest. That asks for a judgement about which parts of the system are the family and which parts are this particular member. The judgement has to be made early, when it is least comfortable and most valuable.
2. The relation that decides everything
The mechanism Parnas gives for this is the part worth taking away, and it is one line of graph theory.
Every system has a uses relation: which components are permitted to invoke which. Draw it and you have a picture of your real architecture, which is usually not the picture on the wall. Where the relation is a hierarchy, with no loops in it, something useful follows. Every level downward is a working subset. You can cut at any point and what remains still runs, still passes its tests, still does something useful. You can ship it early, test it in pieces, tailor it to a customer, and contract it when a feature dies.
If the relation contains loops, none of that is available. A depends on B which depends back on A, and the two are now one thing regardless of what the directory structure says. The system has exactly one deliverable configuration, which is all of it. Removing anything means unpicking the loop, and unpicking the loop means understanding both halves at once, which is the condition Ousterhout called cognitive load and which is why nobody does it.
Parnas is stricter than most architects about when the relation is allowed to grow. A should use B only if B genuinely simplifies A, only if A is not badly degraded without B, and only if there is some useful subset containing B but not A. Those are three conditions, and a dependency that fails any of them should not exist. I have never seen an organisation apply a test of that severity, which is roughly why almost every large system I have worked in is a tangle.
3. Nobody draws the graph any more
Here is what changes when the code is generated.
An agent asked to add a capability will attach it wherever attachment is easiest. It has the local context and it optimises for the change in front of it, which is exactly the right behaviour for the task it was given and exactly the wrong behaviour for the uses relation. It has no view of the graph, no opinion about whether this dependency creates a loop, and no reason to propose that the surrounding structure should move so the new thing can sit cleanly. Each addition is defensible. The graph degrades anyway, one reasonable edge at a time, which is the same mechanism the last article described for waste and the same one Parnas described for aging.
The four flaws he blamed for uncontractable systems read now like a description of generated code. Components that serve two purposes at once. Components that depend on each other in a loop. Chains in which each link assumes the next one is there. And data structures shared widely enough that removing anything breaks something three services away. Nobody sets out to produce these. They are what you get when volume rises and nobody is holding the graph.
And the loss is invisible for a long time, because contraction is a property you only discover you lack at the moment you need it. Extension keeps working. The system keeps accepting features. Then a regulator kills a product line, or a customer wants the small version, or an acquisition needs one service carved out, and the answer comes back that it cannot be separated. That answer was determined two years earlier by a set of edges nobody looked at.
4. It was actually done
The usual objection is that this is academic, so it is worth knowing that Parnas built it.
From 1977 he led work at the US Naval Research Laboratory to rebuild the flight software of the A-7E, a carrier-based attack aircraft, using his own method under real constraints: real memory limits, real weapons, real pilots. The project produced a module guide, a precise requirements document, and a structure in which the documentation was a product with its own design rather than a residue of coding. As far as I know it is one of very few occasions in the history of the field when a design theory was tested at full scale by the person who proposed it.
Which matters for what happens next. Documentation written after the fact, describing what the code does, is worth very little now, because a model will produce that on demand and produce it faster than you can read it. What a model cannot produce is the graph you intended, the subsets you meant to be able to ship, the dependencies you decided to forbid. Those are constraints rather than descriptions. They have to be stated in advance, and something has to enforce them, or they do not exist.
5. The refusal
There is one more thing in Parnas that belongs in a series about how organisations change, and it has nothing to do with modules.
On 28 June 1985 he resigned from the SDIO Panel on Computing in Support of Battle Management, the group advising the Strategic Defense Initiative on whether its software could be built. With his resignation letter he submitted eight short essays, later published together as “Software Aspects of Strategic Defense Systems”. His ground was narrow and technical. The software could not be made trustworthy, because it could never be tested under the conditions of its only real use, and no amount of funding changes that. He was being paid a great deal to say something else. He said he did not wish to take part in misleading the public, and he left.
MacIntyre’s virtues sit underneath this whole series, and this is the cleanest case of them operating inside a technical practice. Truthfulness about what the discipline can deliver, and courage. Every senior engineer currently being asked whether a generated system is safe to ship is standing in a smaller version of that room, with the money pointing one way and the evidence the other. The question of what you will put your name to is not separate from the engineering. It is the last part of it.
The next article picks up the practice that keeps a graph clean while it is still cheap, which is Beck and Fowler on small batches and refactoring.
Where this sits: Building, the third of the series' four phases; Learning, Deciding, Building, Transforming. Parnas is carried forward from Deciding into the Information lever, the one that asks how a build sees and describes itself, and the ability to delete is the sharpest test of whether it can. What an organisation gets out of that work is a working system and the capacity to take things out of it. The Build Is the Test sets out the argument these articles run on.
(An Organisational Prompt is something you can do now....)
Organisational Prompt
Try to remove something.
Pick a feature your organisation no longer needs. It exists: an old integration, a report two people open, a payment method retired in 2023, something behind a flag that has been off for a year. Choose one that is genuinely dead, so nobody can hide behind the argument that a customer might want it.
Now ask a team to remove it, and time the answer rather than the work. How long before somebody can say with confidence what else would break? If the answer arrives in an afternoon, your uses relation is a hierarchy and you can still change your system. If it takes a fortnight and three meetings, you have loops, and the loops are the reason every estimate you receive is larger than it should be.
Then do the harder version. Ask what the minimal useful subset of your most important system would be: the smallest thing that could be shipped and still do something worth paying for. If nobody can name it, the system has one configuration, which is all of it, and you are carrying every line of it into every future decision you make about the business.
Do this once a quarter with a different system. The trend is the finding.
Further Reading
David Parnas: Designing Software for Ease of Extension and Contraction (IEEE Transactions on Software Engineering, March 1979). The paper is behind a paywall; Adrian Colyer’s summary is the best free account of it, and covers the uses relation and the four flaws.
David Parnas: Software Aspects of Strategic Defense Systems (American Scientist, 1985, and later Communications of the ACM). The eight essays that accompanied the resignation, free in full. Read the first three for the argument about why some systems cannot be trusted, and read all of them for the tone of a professional declining to be useful.
Parnas again, with Paul Clements: A Rational Design Process: How and Why to Fake It (1986). Free, short, and more relevant now than when it was written, because the gap between how the work happened and what should be recorded has never been wider.
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.