Comments on: A Response to a cowardly programmer http://jtonedm.com/2009/04/22/a-response-to-a-cowardly-programmer/ James Taylor on Everything Decision Management Sat, 20 Mar 2010 01:10:43 -0700 http://wordpress.org/?v=2.9.2 hourly 1 By: John http://jtonedm.com/2009/04/22/a-response-to-a-cowardly-programmer/comment-page-1/#comment-14223 John Fri, 24 Apr 2009 13:25:59 +0000 http://jtonedm.com/?p=1872#comment-14223 "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. “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.

]]> By: Mark Eastwood http://jtonedm.com/2009/04/22/a-response-to-a-cowardly-programmer/comment-page-1/#comment-14219 Mark Eastwood Thu, 23 Apr 2009 20:45:12 +0000 http://jtonedm.com/?p=1872#comment-14219 James,    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 <strong>overwhelmingly</strong> succeed.   Mark James,

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

]]> By: Paul Vincent http://jtonedm.com/2009/04/22/a-response-to-a-cowardly-programmer/comment-page-1/#comment-14216 Paul Vincent Thu, 23 Apr 2009 10:40:54 +0000 http://jtonedm.com/?p=1872#comment-14216 The main thing is that <strong>business logic needs to be maintained</strong> - 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. Cheers 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.

Cheers

]]> By: Tony http://jtonedm.com/2009/04/22/a-response-to-a-cowardly-programmer/comment-page-1/#comment-14206 Tony Wed, 22 Apr 2009 20:45:57 +0000 http://jtonedm.com/?p=1872#comment-14206 JT - there's always one. JT – there’s always one.

]]>