[nybblesio]

Separate policy from mechanism. [1] I usually reframe this as separating the what from the how. Back in the 80s and early 90s people would commonly call this "data driven design" (this is distinct from "data-oriented design" which lives more in the how).

One area you can quickly see this in action is with user interfaces. So many modern applications construct their UI tediously by coding each component and all of the aggregations by hand. If you take a step back, it's usually very easy to see that the configuration of the UI is just data. Why not just build one layout "engine" and feed it data to generate your UI? The engine part can use whatever hotness you like, but you only have to write that code once. The configuration of the UI (the policy) is what changes frequently (the business requirements); not the mechanism underneath. (This doesn't mean you won't have to change the mechanism, you will. It just requires change at a much slower pace and the changes are bound within the context of the mechanism itself.)

This approach separates layers of a system which have different change vectors and velocities. The mechanism tends to have a much lower rate of change and it's where we programmers like to live. Build tools for "the business" -- whatever that means in your context -- so they can maintain as much of the policy as possible.

If you think through designs like this; however, you will realize that our modern fascination with massive "scaling" of teams is no longer attractive. This may explain why it has fallen out of favor.

[1] https://en.wikipedia.org/wiki/Separation_of_mechanism_and_po...