I got a comment recently from “Joe” who was too much of a coward to actually post his name, his email or to link to his own blog/site/twitter feed. You can read it on my post Here’s a couple of skills developers will need in the years ahead. His comment was so indicative of the kind of nonsense I hear from the least talented among the programmers with whom I meet that I thought I would address it here, item by item:
I think you regurgitate a lot of information from press releases.
Nope – every word is mine and written in response to Q&A with product managers, customers etc. This is the standard complaint made about anyone being positive about anything that isn’t “real code”.
Too bad because if you actually built real systems with the tools you mention, you would realize that the press releases have a lot of hype and not a lot of substance.
I have built real systems (though not with rules it is true) and I talk with a lot of folks who build real systems with these products. I know enough about systems development (both inside companies and at software vendors) to know what makes projects succeed and fail.
The best way to summarize the real projects that have used these tools is that the people who use them as they are intended, who follow advice and don’t just try and force fit the technology to the way they like to work, get great results. Used the way they are supposed to be used BRMS products generate the results their makers so they do. Dozens of customers, many different products, companies of every size and in every industry. These products do what they say they do. Period.
You do realize that all the systems you’ve mentioned are built from the languages/platforms you shun and intended to complement and not replace them, right?
Well duh, of course I do. BRMS products do complement Java/C# etc and they do it by managing the business logic that drives decision-making. The plumbing, the technical guts, is still going to be coded or at the very least modeled in a very technical way.
I am not shunning the languages so much as shunning those who would use these languages when they are manifestly unsuitable simply because they are familiar with them. Even Joe, I hope, would not insist on writing data management functions in some low level language instead of using a DBMS because, after all, the DBMS is written in a low level language anyway…
You tout the ability to manage rules in a BRMS, but have you ever tried searching for rules in products like Blaze Advisor? Ha ha…I’d take procedural code and grep any day of the week
This is my favorite. Find some feature of the BRMS – in this case he is picking on an old version of Blaze Advisor and the search function – and then say “clearly procedural code is better because then I have this feature”. Sigh.
The issue is, or should be, can I run my business more effectively if I put the business logic for my decisions into a BRMS rather than into code? This involves considering the tradeoffs – giving up favorite tools with a high geek quotient (like grep) for instance – and outcomes. Even without a search function, I would be willing to bet that a BRMS-based implementation could be modified to support a new piece of legislation more quickly, more accurately and more transparently than the equivalent procedural code. THAT is what matters.
not to mention that SRL is procedural anway
Fail. Simply not true. Like many BRMSs Blaze Advisor supports some procedural constructs but at its core it is a declarative rules engine. Joe clearly doesn’t get it. But then we knew that already….
