Comment by marcosdumay
7 hours ago
Config values and a configurable plugins system completely solve the problem, dominating over the entire clock.
Iterating further from config values is a great predictor that a project will become a disaster to use, and probably fail completely.
Ah, but what happens when your plugins need to themselves be configured for different client deployments?
You add a few flags, then you need to figure out backwards compatibility as your plugin evolves (which involves defining prioritization rules between options), then those rules get complex enough to have conditionals (say, for granular traffic patterns), which means you have a DSL. And when the DSL gets complex enough, it needs an entire Software Development Lifecycle, which means it's effectively hard-coded. Or, you have people fork the plugin, which is a hard-code in and of itself.
All in all, you don't avoid the "configurability clock," you just decentralize it!
The real problem is that clients inevitably have conflicting needs that cut across any modularization barriers you might think to build. When a configured plugin can have spooky action at a distance, perhaps under-tested due to configuration, is it truly modular? Thus, the clock emerges.
You do multiple plugins or use constant configuration values for them. That's why you want plugins, for putting all complex stuff in actual code that doesn't have to live with the main product.
That doesn't decentralize the clock, it gives a maximum capable interface for the few people that need to handle exceptional cases, and a minimally capable one to the people that just want to use your software as is. That is, you make the product live on two opposite values of the clock at the same time.