Like any programmer, I've been doing rules all my programming career. Every time I write an if-then statement I am writing a rule, in at least one sense of the word.


Until a recent foray into Jess ( via Oracle's implementation) it had always been a part of my everyday working programs. In other words, a true Knowledge Engineer wouldn't call it rules, they would just call it encapsulated conditional logic. So what would happen if I were a seasoned specialist at externalizing rules into a separate rules engine  such as Jess or Blaze or Ilog or Drools ?

I have tutored on and off part-time for years under a brilliant mind in this area, James Owen (currently with Fair Isaac's group). He has guided me through much of the process of learning the basics, whatever I have learned so far. So far in paid contracts, it has been just enough to write and deploy one set of rules, and formulate where to go from here.


Knowing What To Externalize

The process of writing rules centers around externalizing conditional logic, or "if, then" statements. Not all conditional programming is a candidate for externalizing into a set of rules, however. There are many great articles and chapters in most rules books which are there to guide us in choosing what to externalize. The low hanging fruit is what I would identify first, and basic programatic control such as screen and interface logic would probably go last if ever.

So the nut of this portion is that I would khow what conditional logic to externalize, and what not to externalize, if I was a seasoned full time rules programmer, and had been for decades.

Time Budget For Learning What To Externalize

Oddly enough this is one thing I will never have to "learn" formally, as long as I am working in the real world. Stick with me here, I know that sounds like a loco statement.

If I stick with the "low hanging fruit" in every situation, then I can pretty much stay safe. Rarely will any corporate environment budget for me to do anything more than the low hangng fruit anyway. It's only when I get crazy and try to do every if-then statement in a whole code base (not gonna happen thanks) that I would get in trouble on this one ? True ?


Setting Up

Like any other programming situation, I have to get the setup and builds working, make sure all the right jars are in the libraries, such as that.

Time Budget For Setting Up:

How hard could that be ? Basically I do it one time, probably using one of the drools examples, use that to set up my maven archetype, and then use that to build any other project. Other than modifying the version in the pom.xml next time a new drools release comes out, I should be done.



Both rules in general, and whatever specific tool I am using have their own semantics. Some, such as drools, even have their own semantics engines to let you convert your own semantics (DSL or Domain Specific Language) into a rules engine. If I was a seasoned full time rules programmer, I would need to be fluent in these semantics, and also knowleageable of how to convert my own DSL's into semantics that the rules engine could operate on.

An example of semantics would be "salience" which means to the drools engine, the priority or grouping of rules into sequential firing order.

Time Budget for Learning Semantics:

Semantics is something a programmer is always learning and re-learning, so I'm guessing the usual 21 days of working every day in this new set of languages and I should be golden for 80% of what I will be doing, then it's just using a reference to look up the odd entry every once in a while from there out. The chance of me ever getting to the James Owen level might be slim, but not that big a deal either.



Every engine has it's own syntax. Some is borrowed from other languages, others start there and modify. Some are all their own little language. What you need to be able to express in rules is things like this:

game : Game( smallestGuess : smallest )

To be truthful, I can't say in English exactly what that means, which is one of the weakest areas of my understanding. I think it means something like this: If there is a Game object in working memory where getSmallestGuess evalutates to smallest (? the variable or the value ?) and assign it to a variable in the rule named game for later reference.

So the main thing is I would be able to look at every single sentence in a such a rules file, and know exactly what it is, and be able to write that same syntax for any new rule.

Time Budget for Learning Syntax:

Same as semantics above. The average programmer that has been doing this for 20 years or so has already learned maybe dozens of different syntax configurations, one or two or three more is no big deal.


Writing Good Conditional Logic

The whole point of a rules engine is to execute conditional logic. But good conditional logic is just as hard to write in a rules file as it is in a java file ( well, maybe not quite that hard, but still, the point is it isn't all roses either.) I have been stumped so far in writing very long chains of "anded" statements that did not perform as I thought they would.

This is especially true given the fact that externalized rules are precisely where you expect to find the complexity of conditional logic that will stump any normal programmer. I have been told of rules that stretch into dozens of conditions, carefully weaved together.

Time Budget for Learning To Write Good Conditional Logic:

If the syntax and semantics above is about 80% in 21 days of light exercises, then good conditional seems to be the one that would be the inverse. I might get 20% worth a darn in that first period, but it might take me years to get even close to 80% of what someone like James Owen aquires from his years of experience.

This is definitely where the rubber hits the road in rules.


Knowing How To Unit Test Rules

I don't even know if normal rules programmers use unit tests, but I do. So if I go to program rules they better be unit testable.

Time Budget For Learning How To Unit Test Rules:

I give myself about a short half day or less to figure this one out and get some good hello world unit tests done. After that, I'm golden.


Getting Facts In And Out of Working Memory

My one foray into the Jess engine via Oracle Business Rules showed me that getting facts into and out of the "working memory" is not as fully intuitive as I had initially anticipated. There are some interesting constructs that did not fire exactly as I expected them to. So I would of course need to get this fully understood if I am to be a fully seasoned rules programmer.

Time Budget for Learning How To Get Facts In and Out Of Working Memory:

From everything I can gather this one is going to be pretty quick, because the 20 or so examples in the drools-examples download from drools already should have every kind of example I need in this area. I know that I will have to get past that one stumbling block I hit on the Jess engine but unit testing should allow me to get past that.


Getting My Resources All Lined Up

Other than having James Owen to call on weekends, something that one can do after years of acquaintance, I need to have other resources bookmarked and in place. There is a book, for example, that was out of print last time I tried to buy it. Jess in Action: Java Rule-Based Systems (In Action series) that I would have on my bookshelf. Mark Proctor's blog would be in my google reader. All that kind of stuff would be a normal part of my day.

I would also need to be a part of a rules user group, such as our own newly formed Dallas Rules Group.

So that's the way it looks from where I live.

What about you? What would you think I would need to do to be a fully professional seasoned rules programmer?

Time Budget For Getting Resources Lined Up:

I've already been doing this one sub-task for years an hour here and an hour there. My guess is that the Dallas Rules Group will probably also begin compiling some of the same stuff, so may not be that big a deal.