Great article, and definitely made me chuckle -- I've been on this train too with enterprisey code and it's not fun. Often, the road to hell is at least nomina

Great article, and definitely made me chuckle -- I've been on this train too with enterprisey code and it's not fun. Often, the road to hell is at least nominally based on good intentions: beasts like a Rules Engine are as much of design tools ("nothing that can't be solved with another layer of abstraction") as responses to a particular requirement, like the customer -- who is not you, and may not even have a direct line to you -- being able to choose the exact codepath out of the sum total of all delivered codepaths without having to get the developer on the phone to modify the application itself. This is the same line of thinking that led to stuff like Spring beans.xml where person configuring the code on the customer-side can specify which particular implementation of a Kind of Thing to use, out of a larger palette of possible implementations [1]; this system has been decried by many for years to the point of Spring itself adopting a different preferred way of configuring these things, but once your "configuration" can only be changed by recompilation, then it can no longer be called configuration with a straight face. Rule Engines err by swinging too far to the other side of "flexibility", and tend to happen when software is used to model complex systems and ("human") business processes where no single person really understands all the requirements from the very beginning; it's the committee-approved solution to a //TODO: impl, where the, non-technical but hopefully domain-proficient users of the system will be able to teach the system what to do as they go. As the understanding of the system improves, both by the developers and the customers, it then becomes tempting to intentionally constrains the problem space by reframing it in terms of domain-specific concepts. This doesn't necessarily mean writing a domain-specific language (DSL), but it can. This is where the article's premise starts to stretch too much, though: if the quip of "now we're hardcoding everything in a crappier language" can be considered by true, then the DSL has been bungled from the start -- and you haven't reduced the complexity of the problem-space; you've increased it. Now you've got two problems. Nonetheless the clock metaphor is illuminating because of the cyclical tendency of increasing flexibility as the requirements are poorly understood, vs. augmenting the domain model once the requirements are better known. [1] https://news.ycombinator.com/item?id=13683547 https://news.ycombinator.com/item?id=13683547