About Drools

Drools - JBoss Community

Drools - The Business Logic integration Platform

Drools 5 introduces the Business Logic integration Platform which provides a unified and integrated platform for Rules,Workflow and Event Processing. It's been designed from the ground up so that each aspect is a first class citizen, with no compromises.

Purpose of C. Dannevig's Team (Known IT)

They decided to switch to the Drools rule management system (a.k.a. JBoss Rules) v.4 from their homegrown rules implementation to centralize all the rules code at one place, to get something simpler and easier to understand, and to improve the time to market by not requiring a redeploy when a rule is added.

In a word: the team trust Drools much more than their homegrown one, with barely knowledge of the tool other than something they learn from JBoss's ads.

Problems and Reasons

However Drools turned out to be more of a burden than help for the following reasons:

Too little time and resources were provided for learning Drools, which has a rather steep learning curve due to being based on declarative programming and rules matching (some background), which is quite alien to the normal imperative/OO programmers.
Drools’ poor support for development and operations – IDE only for Eclipse, difficult debugging, no stacktrace upon failure
Their domain model was not well aligned with Drools and required lot of effort to make it usable by the rules
The users were used to and satisfied with the current system and wanted to keep the parts facing them such as the rules management UI instead of Drools’ own UI thus decreasing the value of the software (while increasing the overall complexity, we could add)

The Result

At the end they’ve removed Drools and refactored their code to get all rules to one place, using only plain old Java – which works pretty well for them.

Lessons

Their experience has a lot in common with many other cases when a tool, a framework, or a library are introduced to solve some tasks and problems but turn out to be more of a problem themselves.

Think twice - or three or four times - before introducing a heavyweight tool or framework. Especially if it requires a new and radically different way of thinking or working.
Using an out of the box solution sounds very *easy* – especially at sales meetings – but it is in fact usually pretty *complex*.
(Rich Hickey: InfoQ: Simple Made Easy)We should strive to minimize complexity instead of prioritizing the relative and misleading easiness (in the sense of “easy to approach, to understand, to use”).
“I’ll do it all for you, be happy and relax” tool turns into a major obstacle and source of pain

Cost of introducing a new library, framework, or tool

Complexity
Competence
Development
Operations
Defects
Longevity
Dependencies

My Thought

Basically, this is a good post, and I like its analysis. However, I don't like the conclusion. Especially, I don't like the idea of "Thinking" and returning back to the original tools.

The problems of Known IT team met could be generalized into these two:

Unexpected results
Changing costs.

These problems could be resolved by introducing a prototype development team with two to five senior developers, focusing on the new tool for about two months. Ideally, they could develop a real project using the new tool. After that, the team would gain a lot of knowledge about the new tool without wasting too much money and time, and would make a better decision based on their real experience within the team/company.

My suggestion is: don't think, do it, with minimal cost.

Travel of Software Developer

27.11.11

How to Fail With Drools or Any Other Tool/Framework/Library | Javalobby