There's a book I like called "Design Rules: The Power of Modularity"; it was written by some business professors in 2000 and is loosely about the industrial organization and the history of IBM's System/360 (the first "modular computer family") and more generally about how modularity enables innovation and growth.

They enumerate what they call "modular operators" which are basic ways a system can be changed:

* "splitting" a design into modules

* "substituting" one module design for another

* "augmenting" adding a new module to the system

* "excluding" a module from the system

* "inverting" to create new design rules

* "porting" a module to another system

It doesn't matter here whether the modules are functions, computer programs, hardware components, business units, 2 pizza teams, or companies in an industry (Intel, AMD, RAM manufacturers...).

Modularity is a core part of the Unix philosophy. Unix itself is an operating system and involves some particular concepts (pipes, files, processes).

It seems obvious that the concepts for an operating system (pipes, files) will be less relevant in a different domain (say, web programming).

While I agree that maybe the Unix abstractions aren't appropriate for new problems in different domains, I think some parts of the Unix philosophy (i.e. modularity, minimalism, and compositionality) still deserve consideration.