[HN Gopher] On the criteria to be used in decomposing systems in...
___________________________________________________________________
On the criteria to be used in decomposing systems into modules
(1972)
Author : reverseflux
Score : 109 points
Date : 2025-03-03 18:16 UTC (3 days ago)
(HTM) web link (dl.acm.org)
(TXT) w3m dump (dl.acm.org)
| flafla2 wrote:
| One of my favorite ever papers and very ahead of its time. Thanks
| for the share :)
| bobbiechen wrote:
| This paper is 50+ years old and yet programmers are still making
| the same mistake of defining modules based on a flowchart,
| instead of modules that hide design decisions. I think that shows
| the youth (and perhaps lack of foundational training) of software
| engineering as a field.
|
| But also the progress of the last 50 years: the KWIC index went
| from "a small system [that] could be produced by a good
| programmer within a week or two" to a tiny system that can be
| written in a couple lines using the standard library of Java (as
| I once saw a demo of).
|
| Also: I recently wrote a blog post related to this paper and all
| of the initial test readers told me they had no idea what a KWIC
| index was and it needed more explanation. Instant full-text
| search really changes things.
| esafak wrote:
| ... then came semantic search, and AI search, which just spits
| out the answer. I had not heard of KWIC either.
| mistrial9 wrote:
| > defining modules based on a flowchart, instead of modules
| that hide design decisions
|
| ok - "modules that hide design decisions" implies OOP. In
| thirty years, OOP got applied to build giant systems, some that
| went too far. There has been backlash against OOP for real
| reasons, perhaps also ignorant reasons too.
|
| Flowchart coding is straight from "structured programming" an
| advance from the single line of execution ASM style that
| sometimes created unintuitive and needlessly-complicated
| execution flow. IMHO there is nothing wrong with structured
| programming, or actually OOP when used appropriately.
| whstl wrote:
| _> ok - "modules that hide design decisions" implies OOP_
|
| It doesn't. Implementation/design decision hiding also exists
| in procedural, functional and in other paradigms.
| mistrial9 wrote:
| I didn't say "it demands OOP" I said "implies OOP" .. what
| you say is true also
| rramadass wrote:
| > "modules that hide design decisions" implies OOP.
|
| No; it is the other way around.
|
| OOD/OOP implies information hiding/encapsulation.
| augustk wrote:
| No, "modules that hide design decisions" implies modular
| programming. I think schools should teach modular programming
| before object-oriented programming. Then this confusion
| wouldn't arise so often. For a small modular programming
| language (which also supports OOP), have a look at Oberon:
|
| https://www.miasap.se/obnc/oberon-report.html
| jimbob45 wrote:
| As a hammer to be used on every single problem, OOP is
| unbearable. As a tool used when appropriate, OOP is
| delightful and I get very mad when languages think that they
| are above implementing it.
| fabianholzer wrote:
| Coincidentally, I reread the paper last weekend, and that side
| remark, about how the KWIC index would take a week or two to
| implement got my attention. So, I took the short specification
| given in the paper, and wrote it down in two dozen lines within
| a few minutes. I wrote it up as a blogpost just yesterday:
| https://holzer.online/articles/2025/03-05-kwic-quickly/
|
| With a bit of cocktail napkin math that more than a factor of
| 100 faster than Parnas' estimate, just for having a higher
| language with a reasonable standard library at your hands.
|
| Fred Brooks wrote in his 1986 "No silver bullet" essay that
| "There is no single development, in either technology or
| management technique, which by itself promises even one order
| of magnitude improvement in productivity, in reliability, in
| simplicity.". - but the compound effects of many years of many,
| many gradual improvements in developer tooling are really not
| bad.
| bobbiechen wrote:
| Yeah! I liked your blog post :)
|
| We can all be 100x programmers, if we look at a broader
| timespan.
| mateo411 wrote:
| The paper came out in 1972 which is the same year that C was
| invented. I don't think the paper mentioned what programming
| language was used, but since it has function calls with
| parameters, it's a higher level language than assembly.
| commandlinefan wrote:
| I see this mistake in project planning as well: I'm asked to
| scope how long it will take to complete module #1, then how
| long it will take to complete module #2, then module #3, etc.
| but in reality they all end up going hand-in-hand but depend on
| some common work that's "invisible" to the planners.
| aqueueaqueue wrote:
| You sort of have to go along with it if you want to estimate.
| The perfect plan and estimate only happens after the
| completion date.
|
| There are so many unknown deps and unknown opportunities to
| optimise at the start of a project.
|
| You find those out as you get in the weeds and as the ICs
| dream a 1am about their code and bring that idea in the next
| day.
| Jtsummers wrote:
| It still surprises me there hasn't been much discussion on this
| article here. The only three submissions that got any traction
| previously:
|
| https://news.ycombinator.com/item?id=37477446 - Sept 2023 (15
| comments)
|
| https://news.ycombinator.com/item?id=30138468 - Jan 2022 (27
| comments)
|
| https://news.ycombinator.com/item?id=8849468 - Jan 2015 (5
| comments)
| o_nate wrote:
| Maybe I'm cynical, but I think most people probably comment
| without reading things all the way through, and in this case
| you can't just read the first paragraph and get the gist of the
| article. It takes a bit of time to digest the examples.
| kqr wrote:
| This is one of the articles that influenced me most. I did write
| two articles trying to tie it into some other books I've read on
| software design, the first being
| https://entropicthoughts.com/software-design-tree-and-progra...
| WillAdams wrote:
| For a more recent text which touches on this see John
| Ousterhout's wonderful book:
|
| https://www.goodreads.com/book/show/39996759-a-philosophy-of...
|
| which has been discussed here previously:
|
| https://news.ycombinator.com/item?id=42456492
|
| https://news.ycombinator.com/item?id=43166362
| rramadass wrote:
| _Software Fundamentals: Collected Papers by David L. Parnas_ is
| an excellent compendium of Parnas ' papers. You will find more
| wisdom here than most books on "Software Engineering" being
| published today.
| yodsanklai wrote:
| I noticed many programmers don't care about modularity. Some
| people can handle complexity better than others and don't see the
| need for it.
___________________________________________________________________
(page generated 2025-03-06 23:01 UTC)