Copyright © 2009 James Taylor. Visit the original article at Business Rules to Programmers – Methink thou doest protest too much III.Syndicated from ebizQ
Concluding my response to – Programming Sucks! Or At Least, It Ought To it’s time to answer the specific comments I got. First, the reasonable ones:
Ken said:
It depends on the business requirement. […]
Copyright © 2009 James Taylor. Visit the original article at Business Rules to Programmers – Methink thou doest protest too much III.
Syndicated from ebizQ
Concluding my response to – Programming Sucks! Or At Least, It Ought To it’s time to answer the specific comments I got. First, the reasonable ones:
Ken said:
It depends on the business requirement. If business rules need to be changed on the fly then a rules engine framework makes the most sense. If, as in the case of the example, the rules don’t need to change then coding it directly makes the most sense. I think the purpose of the article was basically don’t do more work than is required. Adding complexity will only make it harder to maintain.
I agree that if the rules need to be changed on the fly that a rules management system makes the most sense and that adding unnecessary complexity is a bad idea. I do think that business rules management systems (BRMS) can be useful even when on-the-fly rule changes are not needed – for instance if there is both regular change to the rules and a high domain knowledge required to make rule changes effectively. Even if programmers are still going to maintain the rules, using a BRMS can make it easier to do so for them and provide much better compliance and audit capabilities. As I said in Hardcoding + procedural code = bad news it is not hard-coding per se that is bad but hard-coding in an old-school, procedural languages.
Lynn also engaged in debate rather than vitriol and said:
I think that there is a time and place to hard code in business logic. Alternatively, I think some systems require a complex rule editor, complete with a nice GUI front end for managing rules and generating rules.
It is not realistic to expect most users to be able go in and hand-edit a text config file. It’s also not a very clean approach to have business logic in-line in the middle of an onClick event. It really does come down to individual cases, and somebody else brought up a great point: if you’re a consultant working under a budget or an in-house employee with a deadline, it seems perfectly reasonable to take the minimalistic approach of hard-coding rules in, but try to keep rules organized with the business objects that they apply to.
Again, good points. The consultant on a deadline with a client who is too stupid to think about ongoing maintenance costs is, indeed, in a hole. One of the things I spend a lot of time on with clients is getting them to think about total costs of systems – including programmer time/cost as well as software/hardware budgets and including ongoing maintenance cost as well as development cost. It is very hard to make sensible decisions about any of this stuff if you don’t consider the costs and benefits holistically.
Neal pointed to Ayende’s article on Enabling change by hard-coding everything the smart way. This is an article I have seen before and commented on (in Hardcoding + procedural code = bad news) and it illustrates one of the classic responses to pressure from folks like me to consider a BRMS. The author describes how you can still hard-code the rules but “have a structure to it” that supports on the fly deployment because “Deploying a DLL containing this class to a specified folder will automatically pick it up and run it at the appropriate times”. He describes this as “incredibly simple” because he can still hard-code the rules but can support more rapid updates of rules in a production system because “all we need to do is to provide a FileSystemWatcher and reload them. If we want to add a rule, we just create a new class for that. If we want to modify a rule, we go and change the hard coded logic.”
Wow. Only a programmer would regard this as simple. Writing all this code just so you don’t have to change the way you think. A BRMS can be bought off the shelf that ALREADY DOES ALL THIS! Why write all this code (that will have to be maintained by the person who comes after you)? Why not take advantages of the versioning, reporting, impact analysis and more that comes in a BRMS? If you need to manage the rules then use a tool to manage them – don’t write one! This is like saying you can write the code you need to store data on a hard disk instead of buying a DBMS.
OK, enough of the reasonable responses. Let’s get on to the insults and silliness.
Adam took the classic approach of trying to misinterpret what I said:
So you assume an end-user is competent enough to write their own rules on the fly? I guess we’re all out of work.
Nope. I assume that the people who run the business understand how it is supposed to go better than you do as a programmer and that you should architect systems that bring them in rather than shut them out. IT and business skills are essential for effective systems – the obsession of programmers with the idea that they have to provide BOTH kinds of skills and that “users” are just consumers of their genius is what irks me. He goes on to say:
How many third-party “design your own forms” architectures are there on Google? I’ll let someone else be surprised.
No idea what he meant by this
This article being so generalized, makes it difficult to make a specific argument without changing the direction of the topic, which may have been the intention…but I will say even 2-tier development with hard-coded business logic allows for maintenance ease as well as scalability.
It is certainly true that good architecture and good design can make the management of hard-coded business logic easier. I just don’t think it goes far enough when talking about decisions and decision logic. Rakesh took issue with my maintenance comment:
Why do some spend 75% of their budgets “just changing the code”?”
Because they generally take your advice rather than Alex’s.
Actually no. IT departments that use business rules regularly report much lower maintenance budgets than their peers – go ask Gartner or IDC or Forrester about their surveys. Dave said
Each time I read articles about rules engines, I mentally replace “rules engine” by “Microsoft Access”. Puts things in perspective…
Beats me why he thought this added anything. Microsoft Access is a database and one aimed at small projects. A BRMS may be like a DBMS in that it manages rules the way a DBMS manages data and there are rules engines that have Access-like characteristics but there are also open source and commercial-grade BRMS products that bear as much resemblance to Access and his comment does to common sense. Next, Eric accused me of being ridiculous:
In a world of deadlines your approach is just ridiculous. You’re actually suggesting that untold effort be put towards a system that may, or may not, be used to modify business rules. I especially like the rationalization that normal people (read: not programmers) should be doing business rule modifications. Wow…
I don’t know about everyone else, and I may definitely be alone here, but I’m paid to build what the client wants, and the project needs, not go off into hypothetical land and build all sorts of functionality that fixes obscure edge conditions that may never happen. Wow…
Just a quick estimate on time to build and test / debug a system like you recommend compared to the time needed to modify the source and test it seems like a no-brainer. Especially since there’s no guarantee business rules will change.
Then he gets rude. Anyway his point that you can be on a project where the client is focused only on getting the first version done is valid – you’re just stuck. However, many projects NEED flexibility and agility, it’s part of the spec. I addition the evidence is that the business rules WILL change – policies change, regulations change, competitors change, the market changes. If any change requires a programmer (typically not the programmer who wrote the code) to go in, find the code, change and re-test then the maintenance cost and backlog will grow. And I love the assumption Eric makes that programmers understand the business better than the people who run it do – love that programmer arrogance. CM, in contrast, was nice enough to give me “the benefit of the doubt” and went on to point out that the little snippet in the original article was not enough to justify a rules engine (which it clearly isn’t).
It boils down to deadlines – if a program is commented well like the snippet suggests, then I would have ZERO issues with trying to updated the business rule contained in the above code. If the program had neverending business rules and they changed all the time – chances are we would implement a system to manage them. It comes down to time, requirements, and resources. You cannot generalize something like this with a snippet of this size.
All things with which I agree. CM gets rude after that but that just goes to show that someone ca be smart and rude/stupid in successive sentences. Of course you would not use a BRMS to manage 3 or 4 rules. I assumed that the original example was a sample and was make a more general point. Sigh. ammoQ added a classic misunderstanding:
Rules in a rules engine are just code, just like VB code or cobol code. Adding another layer of abstraction serves nothing. Business users could change the rules by themself (sic), but in most cases, they don’t. They call the IT department to do that.
First, rules in a rules engine are not just like VB code or COBOL code. Each rule is managed and manageable, version and stored in a database or repository. Rules can be grouped and managed by business structure not just by program structure and edited independently. Rule management is much more effective when the rules are managed as rules not as code. And business users do change the rules themselves – they just do it OUTSIDE the hard-coded monstrosities that ignorant programmers have built them.
Javier merely asserts that as a consultant it is in my interest to recommend something slower, harder and more expensive so I’ll ignore that one, the anonymous one who said they would “never hire the programmer who wrote this article” and Garcia who called this “quite possibly one of the dumbest IT articles I have read in my life”. None of them actually tried to understand what a BRMS does, none of them have used a modern BRMS and all of them are convinced that only the programming priesthood should be allowed to change systems. Ho hum.
Well that was fun. Maybe some of these folks will comment again, maybe some of my other readers will chime in.
Have fun
