[scarface74]

That says a lot that the code was not written in its optimum way. Treat that as a bug, and debug why the details cannot be easily retrieved.

I wrote code dealing with railroad car repairs years ago.

https://www.railinc.com/rportal/documents/18/260737/CRB_Proc...

Should I be able to remember all 200+ pages of the audit rules by heart for both the car owner side and the repair shop side and remember why I wrote all of the special cases?

[gizmo686]

If you are writing special cases because a 200+ page rulebook says you need them, then the special cases should be commented to indicate exactly what rule they are meant to address such that someone with the rulebook can quickly look it up.

Ideally, you would have all the rules encoded in a central place so this lookup becomes obvious from the structure of the code, but that is often not possible.

I am involved in a simmilar project now. We have a proprietary data format which has, over the years, evolved slightly different versions as different teams extended it in slightly different and incompatable ways. The code has all kinds of special cases, to the point where we developed internal style guidelines for how to comment them

[scarface74]

So now you have the rule book and the comments and if there is a bug in any of the code, an I suppose to remember what all the code does and think through it? Am I suppose to be able to just think through why the one set of hundreds of records that came from one of 200+ repair yards is giving back erroneous results or should I just use a debugger and set a conditional breakpoint?

[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.