4 ms·
> This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I’ve built systems bo
by crgwbr 7y ago
> This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases).
I’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple the time debugging configuration of complex business rules systems than I would have if it was just written in code and unit tested.
- mrdoops 7y agoAgreed. I guess my point is that we need to focus more on making declarative business rules systems more tenable as an approach in general. If we consider the framework + CRUD generators as the most productive way to build a web app (probably has been since Rails) - that's a result of tooling built around an approach. What happens when we focus similar efforts of tooling towards these Rule Based components?
- closeparen 7y agoOne cool trick here is to use a restricted subset of a programming language as your rules configuration format. That way it still feels accessible to stakeholders, but you also have access to the other software development paraphernalia (tests, static analysis, version control, etc) if you want it.