
It’s old. The examples are in PL/I. But his framework for identifying “Functional Strength” and Data Coupling is something every developer should have. Keep in mind this is before functional programming and OOP.
I personally think it could be updated around his concepts of data homogeneity. Interfaces and first class functions are structures he didn't have available to him, but don’t require any new categories on his end, which is to say his critique still seems solid.
Overall, most Best Practices stuff all seem either derivative of or superfluous to this guy just actually classifying modules by their boundaries and data.
I should note, I haven't audited his design methodologies, which I'm sure are quite dated. His taxonomy concerning modules was enough for me.
"The Art of Software Testing" is another of his. I picked up his whole corpus concerning software on thriftbooks for like $20.
I nominate Stepanov's Elements of Programming to the second list. Beautiful, dense, and a perpetual shelf ornament. Stepanov's papers, especially the one that launched the STL, Fundamentals of Generic Programming (with James Dehnert) is a masterpiece.
I have some favorites that show my age:
Software Tools by Kernighan and Plauger. Can be thought of as the poor-man's Dragon book.
The Practice Of Programming by Kernighan and Pike. As if the UNIX way needed any defending after almost 40 years.
Reliable Software Through Composite Design and Composite/Structured Design by Glenford Myers. You have to get past the ancient languages and flowcharts. These books describe modularity and module strength and coupling and are full of good ideas that still apply.
Database In Depth by C.J. Date, for programmers who haven't read Date's textbook on databases and probably don't need to. I do wish the NoSQL weenies would read Date's Introduction To Database Systems for some history and humility. Database technology has been there, done that, moved on.
He mentions that back in the 70s he was writing Fortran for NASA and his mentor recommended he read a book called Composite/Structured Design. "Structured Design" was the big thing back then and the controversy was using if-else and while loops instead of Gotos. Nobody was worried about strongly vs weakly typed langauges (perl!).. Key chapter in that book is on Coupling and Cohesion.
Junp to the late 90s for his second book recommendation: "What Every Programmer Should Know About Object-Oriented Design", really just the third part of the book which introduces "connascence". Two pieces of software share connascence when a change in one requires a corresponding change in the other.
I love the historical angles on this stuff.