6 ms·

On the criteria to be used in decomposing systems into modules (1972) [pdf]

106 points by camnora 5y ago

Jtsummers 5y ago
I really thought there had been a previous submission with more comments, but maybe it was another Parnas paper. The only past submission with comments: https://news.ycombinator.com/item?id=8849468 https://news.ycombinator.com/item?id=8849468 - Jan 7, 2015 (5 comments)
- dang 5y ago
  I thought so too, but couldn't find one.
- jonjacky 5y ago
  A Rational Design Process: How and Why to Fake It https://news.ycombinator.com/item?id=11101358 https://news.ycombinator.com/item?id=11101358 From Feb 2016, with just 2 comments. The paper is much better than the comments would suggest.
  - Jtsummers 5y ago
    Maybe we need a Parnas day/week here on HN. A lot of his papers have shown up here, but seem to be light on comments in a lot of cases.
User23 5y ago
> Conclusion We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules. This aligns well with my experience, even if the terminology feels a bit dated.
- nerdponx 5y ago
  This is a great piece of advice and definitely applies to software development in 2022. It probably even applies to system and organization design in general.
  - toss1 5y ago
    Yes, isolating design decisions and modules that can change independently is fundamental. I also found one of the essential keys in the first paragraph, which unfortunately didn't seem well discussed in the paper: >> At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules I've found it extremely useful to clearly and fully define the interfaces before coding. When this is done well, it should be the case that separate (module) teams can really develop and even test independently, as they are really just "throwing it over the wall" when communicating with another module. This also enables far easier scaling, as one can focus scaling (e.g., adding more hardware) to just the essential parts of the system. So, it ends up being worth it to even either deeply analyze the range of possible interactions between the modules, or even build small simulators or throwaway versions just to really understand at the outset the elements needed in the interface.
- deleted 5y ago
  [deleted]
- _0w8t 5y ago
  There are clear cases when the approach advocated in the paper just does not work. For example, one cannot hide behind an abstraction the difference between a reliable local and unreliable network storage. Another problem is that designing module boundaries to minimize the future changes require to anticipate what may change. But as the saying goes, “it is really hard to predict especially about the future”. If the prediction was wrong, then the initial split into components was hiding the wrong thing. For example, in the example in the paper they assumed that the task would stay the same, only hardware or the size of data set would change. But allow to change the task, and the whole proposed module split becomes wrong while design based on what was called flowcharts in the paper could require less rewrites.
pixelmonkey 5y ago
Modern analysis of this classic David Parnas paper by Adrian Colyer (in The Morning Paper) here: https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/ https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us... This is the paper known for introducing/elaborating concepts like "modularization" and "information hiding".
goto11 5y ago
Why are those PDF's so ugly? It would be so much more readable if it was just a regular web page. (And sorry for the negativity since this is a fascinating article. But I'm genuinely curious why the this PDF is so ugly, since I'm sure the original published version looked significantly better, and the text seems to have been OCR'ed)
- Jtsummers 5y ago
  Google can help you out: http://sunnyday.mit.edu/16.355/parnas-criteria.html http://sunnyday.mit.edu/16.355/parnas-criteria.html (4th result for me)
  - goto11 5y ago
    Thanks!
- _Microft 5y ago
  Have a look at the footer of a page of the PDF. It says „Communications of the ACM, Decembre 1972, Volume 15, Number 12“ there. It is a scan of an old article from a journal.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
goto11 5y ago
This also pertains to the much-misunderstood "Single Responsibility" principle. The article argues that modules should encapsulate decisions which may change, i.e shield other modules from effect of such changes. The SRP argues that each module should only encapsulate one such decision.
tcgv 5y ago
I always bring up this paper when I read a post criticizing OOP. It's a bit old but still very relevant and practical. In it the concept of information hiding, closely related to encapsulation, was first described. This concept plays a central role in the strategy for effective system modularization and is IMHO the basis of OOP. Shameless plug: A couple of years ago I wrote a post about this paper trying to expand it based on my personal experience and providing a more simpler example to elucidate the concepts presented in it [1] [1] https://thomasvilhena.com/2020/03/a-strategy-for-effective-system-modularization https://thomasvilhena.com/2020/03/a-strategy-for-effective-s...
- lincpa 5y ago
- thewarrior 5y ago
  Loved this post
- yaantc 5y ago
  I don't remember seeing a criticism of OOP that is a criticism of encapsulation. Everybody tends to agree that encapsulation is desirable. It seems to me criticisms of OOP are that it rolls too many things into one construct, the class: it's a type, with encapsulation of methods and data structure, plus inheritance, all into one. And it can lead to not so efficient data placement on modern CPU (AoS vs SoA). Languages like Ada and Ocaml have object orientation extensions to the initial languages (Ada 83, and Caml/SML) that can very often be ignored. And still are very good for encapsulation. With them, modules (packages for Ada) and types are separate. It is very natural to group close types together into one module, while exporting opaque abstract types only usable through a module services. Rolling different concepts into the class may give a more intuitive result at first, particularly when simulating real world entities. But it's also a bit limiting compared to keeping those concepts orthogonal.
  - mvc 5y ago
    I think Clojure quite explicitly rejects "encapsulationism". As does the "data on the outside" philosophy of event driven systems.
gandalfgeek 5y ago
If you're into short (10 min) video summaries: https://www.youtube.com/watch?v=NF5tRQb0Dpc https://www.youtube.com/watch?v=NF5tRQb0Dpc
lincpa 5y ago

106 points by camnora 5y ago

I really thought there had been a previous submission with more comments, but maybe it was another Parnas paper. The only past submission with comments: https://news.ycombinator.com/item?id=8849468 https://news.ycombinator.com/item?id=8849468 - Jan 7, 2015 (5 comments)

dang 5y ago
I thought so too, but couldn't find one.
jonjacky 5y ago
A Rational Design Process: How and Why to Fake It https://news.ycombinator.com/item?id=11101358 https://news.ycombinator.com/item?id=11101358 From Feb 2016, with just 2 comments. The paper is much better than the comments would suggest.
- Jtsummers 5y ago
  Maybe we need a Parnas day/week here on HN. A lot of his papers have shown up here, but seem to be light on comments in a lot of cases.

User23 5y ago

> Conclusion We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules. This aligns well with my experience, even if the terminology feels a bit dated.

nerdponx 5y ago
This is a great piece of advice and definitely applies to software development in 2022. It probably even applies to system and organization design in general.
- toss1 5y ago
  Yes, isolating design decisions and modules that can change independently is fundamental. I also found one of the essential keys in the first paragraph, which unfortunately didn't seem well discussed in the paper: >> At implementation time each module and its inputs and outputs are well-defined, there is no confusion in the intended interface with other system modules I've found it extremely useful to clearly and fully define the interfaces before coding. When this is done well, it should be the case that separate (module) teams can really develop and even test independently, as they are really just "throwing it over the wall" when communicating with another module. This also enables far easier scaling, as one can focus scaling (e.g., adding more hardware) to just the essential parts of the system. So, it ends up being worth it to even either deeply analyze the range of possible interactions between the modules, or even build small simulators or throwaway versions just to really understand at the outset the elements needed in the interface.
deleted 5y ago
[deleted]
_0w8t 5y ago
There are clear cases when the approach advocated in the paper just does not work. For example, one cannot hide behind an abstraction the difference between a reliable local and unreliable network storage. Another problem is that designing module boundaries to minimize the future changes require to anticipate what may change. But as the saying goes, “it is really hard to predict especially about the future”. If the prediction was wrong, then the initial split into components was hiding the wrong thing. For example, in the example in the paper they assumed that the task would stay the same, only hardware or the size of data set would change. But allow to change the task, and the whole proposed module split becomes wrong while design based on what was called flowcharts in the paper could require less rewrites.

pixelmonkey 5y ago

Modern analysis of this classic David Parnas paper by Adrian Colyer (in The Morning Paper) here: https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/ https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us... This is the paper known for introducing/elaborating concepts like "modularization" and "information hiding".

goto11 5y ago

Why are those PDF's so ugly? It would be so much more readable if it was just a regular web page. (And sorry for the negativity since this is a fascinating article. But I'm genuinely curious why the this PDF is so ugly, since I'm sure the original published version looked significantly better, and the text seems to have been OCR'ed)

Jtsummers 5y ago
Google can help you out: http://sunnyday.mit.edu/16.355/parnas-criteria.html http://sunnyday.mit.edu/16.355/parnas-criteria.html (4th result for me)
- goto11 5y ago
  Thanks!
_Microft 5y ago
Have a look at the footer of a page of the PDF. It says „Communications of the ACM, Decembre 1972, Volume 15, Number 12“ there. It is a scan of an old article from a journal.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

goto11 5y ago

This also pertains to the much-misunderstood "Single Responsibility" principle. The article argues that modules should encapsulate decisions which may change, i.e shield other modules from effect of such changes. The SRP argues that each module should only encapsulate one such decision.

tcgv 5y ago

I always bring up this paper when I read a post criticizing OOP. It's a bit old but still very relevant and practical. In it the concept of information hiding, closely related to encapsulation, was first described. This concept plays a central role in the strategy for effective system modularization and is IMHO the basis of OOP. Shameless plug: A couple of years ago I wrote a post about this paper trying to expand it based on my personal experience and providing a more simpler example to elucidate the concepts presented in it [1] [1] https://thomasvilhena.com/2020/03/a-strategy-for-effective-system-modularization https://thomasvilhena.com/2020/03/a-strategy-for-effective-s...

lincpa 5y ago
thewarrior 5y ago
Loved this post
yaantc 5y ago
I don't remember seeing a criticism of OOP that is a criticism of encapsulation. Everybody tends to agree that encapsulation is desirable. It seems to me criticisms of OOP are that it rolls too many things into one construct, the class: it's a type, with encapsulation of methods and data structure, plus inheritance, all into one. And it can lead to not so efficient data placement on modern CPU (AoS vs SoA). Languages like Ada and Ocaml have object orientation extensions to the initial languages (Ada 83, and Caml/SML) that can very often be ignored. And still are very good for encapsulation. With them, modules (packages for Ada) and types are separate. It is very natural to group close types together into one module, while exporting opaque abstract types only usable through a module services. Rolling different concepts into the class may give a more intuitive result at first, particularly when simulating real world entities. But it's also a bit limiting compared to keeping those concepts orthogonal.
- mvc 5y ago
  I think Clojure quite explicitly rejects "encapsulationism". As does the "data on the outside" philosophy of event driven systems.

gandalfgeek 5y ago

If you're into short (10 min) video summaries: https://www.youtube.com/watch?v=NF5tRQb0Dpc https://www.youtube.com/watch?v=NF5tRQb0Dpc

lincpa 5y ago