Dealing with Rule-Based Systems

Building Great Code

I've built a few rule-based systems in my time. Nothing like an Expert System, but enough to know that the business logic of most businesses is a complex thing, and care needs to be exercised in creating the rules, naming the rules, putting the rules into a cohesive system, and in general, making it work. What I'm a little surprised about today is that this isn't something that people seem to naturally pick up on.

I'm looking at code written by a smart guy. He's no dummy. He's got experience as well. Yet it seems that he's into making the worst named rules, and combining rules in ways that it's not clear what's being checked (asserted) in a rule, and why. The resulting combination of these rules is worse that just a series of if/then/else statements because it hides the things that are being checked behind very poorly named methods.

Yikes!

So today I did a lot of clean-up. The rules are clear, more reasonably named - when the functionality changed, and the layout is far better. I was pairing with someone and they weren't able to follow until I made it clear that there really was a "good way" to write these rules, and combining completely different rules into one wasn't really a "winning way".

It's not done, but it's getting closer, and I'm really surprised that this part of the codebase is so easily done. I had expected more, but again, it was blown out of proportion due to the things I'd heard from the people working on it.

Get good data. Understand it. Write good rules. Combine them. It's really not all that hard.