One of the most famous epigrams of programming collectd by Alan J. Perlis is:

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

I'm reminded of this in any discussion where this sales-pitch-black notion of Business Analysts writing  rules by themselves is peddled with the assumption that some cleverly designed non-trivial DSL will magically provide a blue sky and smooth sailing.  Of course the BAs will still have to have a clear understanding of the object model, and of course they will still have to know the basics of rule programming. They'll need good training, and (although I have never seen this) I think that they'll need a lot of baby-sitting when they start.

When you write that "DSL ... gets built up over time" I think I know what you are referring to, but this is more a hint on the way a DSL might be developed, well before it is released for writing rules for production. Changing a DSL - even by just adding new phrases - is tricky due to the way DSL parsing works.

All of this does not mean that it cannot be done or that you cannot do it. Mostly, it is the result of developing a DSL with the intent of demonstrating that rules can be written in a language that can be read and understood by domain experts. (Note what the experts are not expected to do.) According to this, I have the following checklist for a DSL developer:
  1. Design a simple object model with clean linkage between related objects.
  2. Know about all rule condition and consequence patterns that will need to be written.
  3. Make sure that you fully understand the way DSL parsing works.
  4. Decide about the way the BAs will write the rules (GUI editor or text editor).
After (2), you still have the option of using spreadsheets or template-based rule authoring. If 80-90% of your prospective rules can be written by BAs that way, you may still decide to have the rest written by programmers.

IMHO, none of the aforesaid is specific for Drools.

Cheers
Wolfgang




On 1 February 2011 17:08, cclark01 <chris.clark@teranet.ca> wrote:

My company is looking to use Guvnor in a new application we're writing.  Part
of the appeal is the idea that Business Analysts will be able to go and
write rules by themselves.  However, in doing a small proof-of-concept, it
appears that you need intimate knowledge of the object model in order to
write any meaningful rules.

I've read up on DSL and it looks like that might help things, but it also
sounds like DSL is the kind of thing that gets built up over time.

So... what's your experience?  Do BA's or Developers write the rules in your
applications?  Does the complexity of the object model play a role in who
can write rules, or is it just a matter of training?
If you've created a DSL, how easy/quick was it?  If not, any particular
reason why not?

I'm looking for some "real life" experiences so that we can have appropriate
expectations going into the project.

Thanks,
Chris
--
View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Who-writes-your-rules-Dev-vs-BA-tp2398166p2398166.html
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users