Business Rules vs Programming

I got another comment on an old article of mine that is linked to a popular programming site – Don’t soft-code, use business rules. This remains my most commented post and the new comment basically repeats some of the arguments made before – that making a change to code is only hard/time consuming/requires an expensive IT project if the code is poorly designed.

Now I already wrote some fairly extensive responses to the complaints I got:

I got another comment on an old article of mine that is linked to a popular programming site – Don’t soft-code, use business rules. This remains my most commented post and the new comment basically repeats some of the arguments made before – that making a change to code is only hard/time consuming/requires an expensive IT project if the code is poorly designed.

Now I already wrote some fairly extensive responses to the complaints I got:

• Business Rules to Programmers: Methink thou doest protest too much I
• Business Rules to Programmers: Methink thou doest protest too much II
• Business Rules to Programmers: Methink thou doest protest too much III

And frankly I still stand by my comments. The challenges with using code to manage business rules remain – business users don’t understand code and programmers will never understand the business as well as they do, executing the rules is much less of a challenge than managing them so you can find and edit them when you need to and a Business Rules Management System is a proven way to manage large numbers of rules so that IT and business people can collaborate on making sure they are correct and up to date.

I have to say that I like the original article, enjoyed the (colorful) responses to it and think the three posts are a good summary of why I still believe in business rules as a way to manage decisions. If you haven’t seen them before, check them out.