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

https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf

by mavelikara • 3 years ago

74 15 3 years ago

win.tue.nl

gandalfgeek• 3 years ago

(Self-plug) If you don't want to read the whole thing, 10 min video explainer here: https://youtu.be/NF5tRQb0Dpc

jweir• 3 years ago

I love it, a video TLDR for classic (and not so classic papers). Thank you.

DalekBaldwin• 3 years ago

It's difficult to relate this to modern perspectives on software design and architecture because the running example is hard to comprehend. It seems to be an interface to a data structure that may have been useful in certain applications in the context of hardware constraints 50 years ago. It would be great if somebody published an implementation of this example with the variations in C for illustration.

pjmlp2• 3 years ago

Except C is quite a poor example for how to use modules.

TU with opaque pointers can be used for such purposes, and they are, but still fail short of Modula-2, Mesa, CLU and UCSD Pascal, to cite contemporary examples.

rewmie2• 3 years ago

Except C is quite a poor example for how to use modules.

How come? C makes it trivial to create self-contained modules.

michaelfeathers• 3 years ago

To me, the most amazing thing is that he says that it is a problem that would take the average programmer a week back then, but today it could probably be coded in 5 minutes in AWK or Perl.

AugustoCAS• 3 years ago

I disagree, I just left a company in which most teams 'modularized' their code in the way Parnas describes as not ideal. What Parnas describes are low level modules that are now mostly provided by languages, but the same applies to 'business' modules. In the org I left, minor changes in a microservice had wildly unexpected consequences due to a mix of lack of information hiding coupled with large data objects. One example: storing a debit in an account would become a credit when loaded back under some circumstances.

The mentality of most developers there was: How can I make the change described in the ticket by touching as little existing code as possible?

rramadass• 3 years ago

A Classic.

Folks interested in studying more of Parnas' foundational papers should checkout the book Software Fundamentals: Collected Papers by David L.Parnas. A good antidote to "cargo culting".

jeffdoolittle• 3 years ago

+1 to this comment. The book is fantastic. So many good ideas came out of the early 1970s and have been duly forgotten or ignored by this industry. It's time to reclaim them.

dang• 3 years ago

On the criteria to be used in decomposing systems into modules (1972) [pdf] - https://news.ycombinator.com/item?id=30138468 - Jan 2022 (27 comments)

On the criteria to be used in decomposing systems into modules (1971) - https://news.ycombinator.com/item?id=8849468 - Jan 2015 (5 comments)

praptak• 3 years ago

Christopher Alexander, the architect whose work on architecture sparked the software Design Patterns philosophy/movement, also tackled this problem. He obviously didn't focus on software but rather approached this problem from the general design.

His thoughts are in "Notes on the Synthesis of Form" (1964) and I believe his conclusions are similar to the authors of this article: split the design problem into "clusters" of decisions, so as to minimize the dependencies between "clusters".

jalfresi• 3 years ago

"Notes on the Synthesis of Form" is my favorite book of all time. I try to re-read it at least once a year. Thoroughly recommend it.

mro_name• 3 years ago

canonical https://dl.acm.org/doi/10.1145/361598.361623

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

Related Stories