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.
