On the criteria to be used in decomposing systems into modules by D. L. Parnas https://dl.acm.org/doi/10.1145/361598.361623 This is one of my favorite papers, and the basic concept that each design decision should be hidden within a module of some sort, where "module" can mean anything from a collection of procedures to a language specific feature, has served me well for many years. Also, the principle that programs should be broken up by concern and not by the order in which things happen has informed my design decisions for a long time. Has this paper's approach informed anyone else's design over the years? If so, how? What principles do the rest of you use to make your programs more resilient against changes in the specifications?

Parnas theory is based on "information hiding". The bottleneck of collaboration is communication and share understanding. To modularize (or to collaborate) based on minimal information sharing is economic. This also means, to save the cost of end user programming, we need to find the boundary what can be customize, what can not be. If everything is changable, the cost of understanding to tweak will go up.

@taowen that reminds me of a joke we used to make many years ago when a customer would ask for endless amounts of customizability. "Maybe we should just give them a Perl interpreter."

Maybe a little stereotypical, but I have found pace layers a really useful tool for decomposing systems into a layers that move at different speeds. It helps tease out boundaries between layers and provides guidance about how different layers should change.

Fast learns, slow remembers.  Fast proposes, slow disposes.  Fast is discontinuous, slow is continuous.  Fast and small instructs slow and big by accrued innovation and by occasional revolution.  Slow and big controls small and fast by constraint and constancy.  Fast gets all our attention, slow has all the power.

https://jods.mitpress.mit.edu/pub/issue3-brand/release/2 What’s interesting is that this mental model makes you really think about the qualities you want at different layers. The slowest layers should be small, simple, tightly-scoped, and extensible to let other layers innovate at the edges. A detailed example is how web technologies were designed to enable progressive enhancement via pace layers. https://speaking.adactio.com/ZCJ61M