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.
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.
> 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.
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:
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.
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.
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.
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.
Yeah! I liked your blog post :)
We can all be 100x programmers, if we look at a broader timespan.
> 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.
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
> ok - "modules that hide design decisions" implies OOP
It doesn't. Implementation/design decision hiding also exists in procedural, functional and in other paradigms.
I didn't say "it demands OOP" I said "implies OOP" .. what you say is true also
> "modules that hide design decisions" implies OOP.
No; it is the other way around.
OOD/OOP implies information hiding/encapsulation.
... then came semantic search, and AI search, which just spits out the answer. I had not heard of KWIC either.
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)
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.
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.
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...
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
One of my favorite ever papers and very ahead of its time. Thanks for the share :)
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.
[dead]