Twitter isn't really a rules engine as it doesn't have the ability to create workflows or manage rule priority afaik but let's ignore that for a second.
Rules engines are typically a terrible idea and I say this as someone who has worked at two large corporations, one a bank, where rules engines were heavily used so they could avoid having the larger development staff they really needed. Rules engines fail miserably every single time and eventually have to be replaced.
The problem is that as time goes on people who don't know any better end up writing larger and more complex rules and workflows without an understanding of the side effects those rules generate. The end result inevitably becomes a huge mess that is extremely fragile and nearly impossible to follow.
Yes, but for simple, personal rules that won't have any major repercussions if they fail (e.g. email me when I get 10 likes on my last Instagram photo), I can see how they'd be useful.
...not that my hypothetical rule is useful, but you understand what I'm getting at.
Absolutely. For simple, isolated, inconsequential tasks this works fine. The problem is rules engines always start very innocent and simple, then users request the ability to have rules call each other, then they want to store results, etc. In an ideal world this is a good thing but I have yet to hear of any place where rules engines, used at any significant scale, aren't a complete disaster.
Is it typically a disaster because business users are given access to create their own rules and they don't know what they're doing, or because the complexity of the system grows to the point where that complexity is better managed by other tools (version control systems, QA environments, rigorous testing, etc.)?
In my experience, both. It starts with business users creating rules without having a clue what they are doing and it ends with the system becoming so complex that it would have been better off being written by engineers using tools more appropriate for the job.
Typically what happens is that business discovers they can now implement every last feature they desire without getting any push back from engineering so they go wild implementing new features without realizing the consequences. There is no VCS, no QA, no testing. There is no one telling them they cannot do something because it won't scale, it isn't secure or it won't be maintainable.
Their only metric for success is that they get the result they want now and the long term consequences be damned. Worse yet, every single person using the rules engine is acting independently and not as a team. There is no code review, when the rule works to their satisfaction it gets pushed into production.
At first everything works fine and people get promoted for saving money on engineering costs but then the rules start getting more complex, start becoming composed of other rules, need to have more complex actions or need to integrate with third party systems. Eventually the simple rules engine turns into a bastardized programming language that everyone adds onto and never modifies because no one understands how a modification will affect the 4000 other rules in the engine. At that point you end up having to do a complete re-write, which is something I have had the displeasure of doing in the past.
I think businesses still need flexible / easy to use systems that allow end-users to create solutions quickly. This may involve analysts, IT professionals, and devs working together on the same platform. For examaple, an IT pro writes the sql queries, an analyst writes the regression algorithms, and the devs writes the output adapters.
Typically, by the time you get the dev team to fully implement the solution, it has missed its mark and the analysts have moved on.
Players in the mashup landscape are "trying" to provide scalable and robust, yet flexible and easy-to-use systems.
plug - flowreports.co is one of these ... and it can be self-hosted.
Businesses have hundreds of flexible easy systems to let end-users create quick business rule based solutions (particularly for reporting purposes) and have had them since the late 80s maybe earlier, the corporate landscape is littered with them. I wish you the best of luck, that's a tough market to get into.
Thank you for the feedback. Perhaps if we add things like support for version control systems, play well with releasing code to multiple environments, and add UI elements that enforce cloning chunks of code so that changes are isolated and the system can maintain it's coherence even among disparate users we can avoid becoming some of those issues. Something to think on...
That's definitely a step in the right direction. The biggest hurdle you'll have to overcome is getting your application to enforce a process, that's a lot harder than you think it is because people tend to take the path of least resistance and process is rarely that path. You'll have to get buy-in from very high levels of any organization you work with, otherwise things will devolve quickly. Either way, good luck, I'll check out your product demo when you've completed it.
There are very few places where business rules change so quickly that a rules engine is needed. Rules engines are essentially a poor practice used by businesses who don't clearly define what their goals are and stick to them. The alternative is to have a highly modularized system that is flexible enough for engineers to make changes to the code base in a timely manner, but that requires business to sit down and define the problem(s) they are trying to solve with their software. Getting that sort of time investment is difficult.
Rules engines are typically a terrible idea and I say this as someone who has worked at two large corporations, one a bank, where rules engines were heavily used so they could avoid having the larger development staff they really needed. Rules engines fail miserably every single time and eventually have to be replaced.
The problem is that as time goes on people who don't know any better end up writing larger and more complex rules and workflows without an understanding of the side effects those rules generate. The end result inevitably becomes a huge mess that is extremely fragile and nearly impossible to follow.