≡ Menu

A Response to a cowardly programmer


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


Comments on this entry are closed.

  • Tony April 22, 2009, 12:45 pm

    JT – there’s always one.

  • Paul Vincent April 23, 2009, 2:40 am

    The main thing is that business logic needs to be maintained – but programmers hate / find it difficult to maintain others’ code. Solution? Offload business logic to the business via a BRMS and/or use a model-driven approach. With the caveat that “models of business logic” are effectively what BRMSs provide.

    Disclaimer: funnily enough, the idea of regimented (e.g. ruleflow driven) decision services is independent of the need for declarative programming – thence the fact that BRMS tools often have “sequential” / script / procedural modes, aka act like CASE tools.


  • Mark Eastwood April 23, 2009, 12:45 pm


       I’ve been developing decision management applications with BRMS alongside procedural code in a variety of platforms/languages for more than 15 years. I’ve developed with more than one of the leading BRMS products in multiple platforms/languages. Yes, I’ve seen projects succeed and I’ve seen them fail. When used properly they overwhelmingly succeed.

  • John April 24, 2009, 5:25 am

    “Ha ha…I’d take procedural code and grep any day of the week”

    I have to call BS on that one. Having inherited legacy systems where a “rule” is fragmented across multiple source files or multiple scattered IF conditions or obscured by poor variable naming or a side effect of an overly-ambitious SQL statement, there’s not a thing that grepping the source does to help with any of that. 

    A rules-based system gives several opportunities to ease that pain, by allowing the asserted objects to act as a metadata layer on top of the physical data, by allowing the developer to coalesce conditions into more understandable chunks, and, by implementing a declarative approach, to reduce the possibility of blowing your leg off by missing a subsequent chunk of code that alters the conditions of the part you were maintaining. 

    “Joe” has apparently led a development life strewn with rose petals and happy paths.