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 o…
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.