[cratermoon]

Edward V. Berard said, "Walking on water and developing software from a specification are easy if both are frozen." I would seem business rules engines are ideal, because those rules are never "frozen", by nature.

It's true that specifications change faster than software can be completed. That is at the core of the agile manifesto (not to be confused with Agile the industry). There's more than constant change. Part of why specifications are never frozen is how hard it is to specify things at the level of exactness and detail computers require. Vagueness and contradictions are rife, and as programmers one of the reasons we get paid a lot of money is to turn rules into running code. That's another part of the ideas behind the agile manifesto: Get something working in front of the users, adjust what isn't right, and iterate.

Business rules engines aren't magically able to determine what users mean. Someone still has to specify things precisely enough to be executable. The task is difficult enough to require specialized skills: in other words, to require someone who can think like a programmer.

The business user able to specify things in ways computers can execute is so rare as to be near-mythical. What happens when rules engines get deployed, where they make sense, is that there is a team of programmers who are also involved in managing the rules. You might remember the scene in RoboCop 2, where Murphy is so burdened with rules developed by committee he is unable to function meaningfully.

At least one of you who has read this far is about to reply with something about "AI, if not now, at least soon...". I advise pondering carefully before replying.

[Blackstrat]

I knew Ed back in the day. It was a lot of fun watching him interact with my programming staff, mostly C++ programmers. Trying to get them to see that objects printing themselves resulted in excess coupling. Or trying to get programmers to write things down. I still remember laughing when he told them something to the effect of “programmers shouldn’t wear illiteracy as a badge of honor”. Essays on Object Oriented Software Engineering was a good book in the early 90s.

[ivancho]

It's pretty funny that we have a post on how business rule engines are bad because users are not engineers, but also a post on how decision tables are great because users validate the program logic with their domain expertise.

I think there's great value in empowering your coworkers. Most of us don't know how to, so we end up inventing some gnarly DSL, or a glitchy UI admin panel, or we ask medical professionals to learn to write SQL and then feel very engineery when it doesn't work out. But having seen what non-technical people can achieve with just a spreadsheet and sheer determination, I think we're just not very good at understanding what business rule engines and the tooling around them should be able to do. It doesn't help that the majority of them came around the time of XML and SOAP and Java. So instead of rules we make the users write Jira tickets, and instead of local sandbox experimentation we give them hours of QA.