Parnas, 1972: what criterion for splitting code into modules?
Every developer agrees that a program should be decomposed into modules… but according to which criterion?
David Parnas asked himself that question and tried to answer it in 1972.
1972: hide what is difficult or likely to change
His view is that rather than splitting a program into steps taken from a flowchart (a widespread method), it is better to list what is difficult or likely to change in that program, then build each module to hide one of those things from the others.
This strategy brings three clear benefits:
- the program is easier to understand (you can approach it one module at a time);
- the program is easier to maintain (one change = few modules to change);
- the program can evolve faster (people can easily work on modules in parallel).
He adds that a good module design makes the largest possible number of implementations possible, and that to get there, a module’s interface must impose as little as possible on the implementation.
He also warns against a classic trap: thinking that because you have a good module hierarchy, your modules are well designed. Hierarchy and good design are two different things.
2002: thirty years later
He came back to it 30 years later, in 2002, with new insights:
- Unfortunately, decomposing by flowchart steps dies hard (still true in 2026!).
- Unfortunately, economic reasons often mean the extra effort to design your modules well is not made (despite the future payoff! Short term vs long term…).
- Last and most important, he goes further: it is often worth hiding information that will never change too, simply because hiding it allows better implementations.
Parnas’s problem
And in the end… most of the software architecture literature since then (DDD, Clean Architecture, Hexagonal Architecture / Ports & Adapters, Onion Architecture…) tries to answer Parnas’s problem: which strategies and tactics to use for designing a clean decomposition of a complex program…