We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

James Taylor's Decision Management

James Taylor

Don't soft-code, use business rules

Vote 0 Votes

I got a link to this article "Soft Coding" from Reddit today. I have to say that I thought this was an unusually poor article. It boiled down to "I can think of stupid ways to do this therefore that must be a stupid thing to do". Hmm.. The author begins by showing this code:

private void attachSupplementalDocuments()
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I are always required in these states

if (ledgerAmnt >= 500000) {
//Ledger of 500K or more requires AUTHLDG-1A

if (coInsuredCount >= 5 && orgStatusCode != "CORP") {
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A


and goes on to say that there is nothing in that code that "shouldn't be in source code". He says that this implements a very specific business requirement. Of course it does not nothing of the sort unless the requirement was "write this system so that only a programmer can make changes to policy". These are rules, not requirements. He then goes on to say that hard coding is much better than using, not a rules engine (despite the name he gives it) but table-driven code!. As he said,eww. If only programmers can make changes and they are inserting 30 rows to implement a rule then DUH of course it would not work. It won't work because it is not a rules engine! He goes on to argue that you should not use configuration files either, and he is right for all the reasons he gives. What he forgets, or perhaps has not bothered to find out, is that rules engines are designed to allow updates to just some rules and deployment of new rules into running systems precisely to avoid this problem.

He claims that people only worry about this for "the fear that the code we write will have to be changed as a result of a business rule change" and says that "When the business logic changes, the code can change. It's that simple". Wow, what an amazingly ignorant thing to say. If "just changing the code" were so easy, why do IT departments have an application maintenance problem? Why do some spend 75% of their budgets "just changing the code"? Even if it was simple, why should only those admitted to the elite ranks of the programming fraternity be able to make these changes? Why should the business have to wait for them or ask their permission? I could go on but you get the picture. He really hacked me off. It is attitudes like his that are why IT departments are in the mess they are in now.

So what if the business users, or even the programmers, could change this instead:

if thePolicy's stateCode is "AZ" or the Policy's stateCode is "TX" then
//SR008-04X/I are always required in these states

if thePolicy's ledgerAmnt is greater than or equal to 500000 then
//Ledger of 500K or more requires AUTHLDG-1A

if thePolicy's organizationType is not "CORP" and thePolicy has at least 5 coInsured then
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A

and that these could be changed, versioned, added to and removed without affecting each other, would that be better. Well, yes, some. It would be more accessible to business users and less fragile as well as easier to see what changes have been made to which rules by whom, when (which could be important for compliance). It would avoid this kind of problem.

But if you really want business users to maintain this kind of thing, and you do, they need a simpler interface. They need one that hides the rule structure from them and let's them pick the attributes and values they want to use from a simple interface while building the rule behind the scenes. The good news is that business rules management systems let you define these things easily so that the business can own the rules.

Don't hard-code it, don't soft-code it, don't code business rules at all!

, , , ,


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.

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.

How many third-party "design your own forms" architectures are there on Google? I'll let someone else be surprised.

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.

"Why do some spend 75% of their budgets "just changing the code"?"

Because they generally take your advice rather than Alex's.

Each time I read articles about rules engines, I mentally replace "rules engine" by "Microsoft Access". Puts things in perspective...


> Of course it does not nothing of the sort

So . . . it does?

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.

This is quite possibly one of the stupidest things I've ever read. I am now dumber. My head hurts...

Well James is an "independent consultant on decision management, predictive analytics, business rules". So it is in his benefit to take the long road to the goal.


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.

I would never hire the programmer who wrote this article. He would waste time and accomplish absolutely nothing except make something simple more complex.

You are paid to implement business requirements. Not to spend untold hours solve problems that may or (most likely) may not exist.

Epic Fail!!

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, but in most cases, they don't. They call the IT department to do that.

Since this author is a 'consultant' I will give him the benefit of the doubt. This is the mentality consultants use and why IT dept's 'spend 75% of their budgets "just changing the code' - it is most likely code suggested in this article that developers like me would be changing.

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. You just can't and it makes this guy sound like a dolt. My guess is the author is clueless, loves to charge money for 'expert systems', and will remain a 'consultant' for a loooonnng time.


This is quite possibly one of the dumbest IT articles I have read in my life. Congratulations.

If you are actually able to sell your clueless approach as IT "services" for a living, then kudos to you! Your clients must be much more stupid than mine to be OK with you delivering a non-working, incomplete "solution" to their problems that still requires them to code their own business rules by hand before it can be used. That is, if they can actually figure out whatever moronic syntax you require them to use in your fantasy land "rules engine".

Methinks it is a new "head engine" that you need, James.


Programmer's comments about rule management systems are so similar to old discussions about RDBMS. Sure if you have 5 rules that never change you can code them in any language you want. Just like I can use a hardcoded hashmap instead of a real database if all I want is to store 5 pieces of lookup data. But if business logic is really complex with pattern-based object matching, tables, trees, inferencing, etc., and if your business users really need to see or change that logic, then the cost of custom implementation of such solution will go through the roof. And with that spaghetti of deeply nested if's and loops in the resulting code you'll end up with "one change, two new bugs" problem after 50th business change request. I've known old systems written in COBOL that people were afraid to touch for years exactly for that reason, forcing business people not to change their policies even as they became more and more outdated. Rewrite from scratch? Forget about it, nobody wants to sift through all those endless lines of code and reverse engineer the original business intent behind them.

So go ahead guys, hardcode all business decisions (how about 50,000 insurance underwriting policies, egh?), then leave to work for another company and let some other losers handle that cryptic undocumented mess you've created as a part of your job security strategy.

Too bad there was so much hype about rule engines in the past, so people got very high expectations and wrond ideas about what these things are good for.

@Andrei : "But if business logic is really complex with pattern-based object matching, tables, trees, inferencing, etc."

And how often do you see business logic being a complex set of rules based on pattern-based object matching, tables, trees, inferencing, etc? Not that often. That is not to say that typical business logic is not complex. It is, but more often than not it is a discrete collection of related business rules that are pretty much linear and... surprise, simple.

@Andrei : "So go ahead guys, hardcode all business decisions (how about 50,000 insurance underwriting policies, egh?), then leave to work for another company and let some other losers handle that cryptic undocumented mess you've created as a part of your job security strategy."

Reading comprehension. I'd challenge anyone to find any of the respondents suggesting to hard code all business decisions. As for your 50k insurance policies, hardly in the insurance or banking industry you will find the complexity of business rules being 1-1 or even linear to the number of policies being governed by them... unless the enterprise in question has an atrociously developed set of business processes (which would mandate a highly flexible rule engine.) But in general (and overwhelmingly), that is not the case, and, as life would have it, what counts is the solution to general problem.

(Now, let's see if you take my paragraph above as an indication that I'm suggesting we should all hard-code all business rules under the sky.)

You fail to understand the respondents' criticism of THIS article as well as the very narrow example in original article that was being criticized by THIS article.

Whether or not in reality changing the line of code is a problem depends on how long it takes to deploy having made the change.

Unfortunately in too many companies where I have worked, rather than having a proper modular design, in order to install any code change it has to go into the huge "build" system and get deployed with the next full system release.

This usually results in a 2-tier system: scripting languages that can be changed fairly swiftly, and the compiled code which needs to be installed with the release.

Usually this scripting language is proprietary although if you're lucky you will find them using a standard one. Either way, it takes a programmer to maintain it.

Wouldn't it be easier if using, say, Java, to be able to just build a standalone .jar file with the change and have it live within a day without having to do a full install?

James Taylor blogs about decision-management technologies such as predictive analytics and business rules, discussing how they deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links



 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Monthly Archives