Bad Programmers

Solving your skillset problems

Business Rule Engines

There are Business Rule Engines and then there are "Business Rule Engines".

The point of a Business Rule Engine (BRE) is to make large numbers of safe business decisions without human intervention. An example is an online credit application that needs to judge the credit-worthiness of each applicant based on multiple considerations that change periodically. The same term can also describe an alarm system that notifies employees when something non-mechanical goes wrong and needs to be addressed, such as low stock levels or a rise in the frequency of loan defaults.

BREs are difficult to implement properly, so they tend to be commercially developed and sold as packages that must be integrated with a business's other systems. The actual implementation is usually built around an expert system and the rules are coded in a well defined, standardized markup language.

"Business Rule Engines", also called "Enterprise Rule Engines" and "Business Logic Layers" are homebrew attempts to create a Domain Specific Language (DSL) on top of an existing file format, usually the native format of a common desktop application such as Excel or Visio, or by storing each rule as rows in a relational database. They aren't usually adventurous enough to make inferences or enforce consistency, and many lurch awkwardly in the direction of Turing Equivalence. Some are just attempts to please a manager and hijack an existing application's editor to save the effort of writing their own, and some are based on a misappropriated fear of "hard coding" logic.

The main problem with homebrew BREs is that the programmer rarely begins with a clear definition of the problem's scope, and as a consequence ends up writing the entire application in their chickenwire language just so they can accommodate anything the business might think of. They will use a good, well defined and supported language like C or Java to invent a badly designed, buggy and unsupported meta-language, build their application on top of it, and spend the rest of their career at that company patching the sores that inevitably develop.

Furthermore, most usually fail to achieve their original goal of providing management with a way to change the rules without programming, as the contraption quickly becomes so fragile that only a programmer has the skill of making any rule changes and debugging them afterward.

In almost all cases, it is superior to just hire a programmer to write your business rules in C, C#, Java, VB.Net, or whatever, and recompile the program whenever they have to change.