[bartimus]

In this particular case you should probably implement some logging or alternative output that shows how the rules are being applied. Also perhaps the rules shouldn't be part of the code itself. It would be preferable to be able to add/remove/update a rule without needing to deploy a new version of the program (without going down the rabbit hole of implementing an entire logic engine).

[hyperman1]

I once was in a situation like this: Tons of weird rules, straight from the law, which made no sense at all.

Every day someone came along with a bug. After tracing through the code for half an hour, the program was generally proven correct. The business had forgotten some weird edge case of an edge case.

I always wanted to write a small gui program that would list for the business which rules had been applied, and what all intermediate data was.

BREs were to slow, btw, so everything was hardcoded.

[scarface74]

That’s exactly what you end up doing - writing your own rules engine instead of just using your language of choice.

How much harder is it to “deploy your whole” program than changing a complex XML/JSON configuration file or database change, testing it, and then deploying that?

In fact, it’s ususlly much easier deploying code. Setting up a simple pipeline to deploy a service is not rocket science.

[bartimus]

It makes sense to use a programming language for the rule logic. I'm just suggesting you need to conceptually separate the software code from the rule code. Have the rule code in a separate repository that can be deployed independently (by people with different roles). You can't just deploy new code. You'd perhaps want to apply previous versions of a rule.

In any case. The people maintaining/using the rules might not have a debugger available. They still need to have some kind of "rule stack trace" on how the system came to a certain answer.