Business Rules Belong In Files

A bold statement expressed in CaseTools...

Many systems written today have the business rules hard coded in the program. Defining these rules, their relationship to the data and designing a system that allows for the rapid change of these business rules or, for that matter, system rules, becomes the critical path. -- BillMeecham

Yes, but by the time we are expressing rules, we find we must agree on substantial semantics to give meaning to these rules. I've placed my bets on objects because...

they're simple & expressive
they operate at many levels of abstraction
pure object architectures can evolve gracefully

In fact, the best objects, the objects that dramatically reduce the complexity of business logic, will only surface during maintenance. Long term maintenance is the balancing of the continued escalation of requirements with the search for more potent abstraction.

Storing rules in files is not enough. -- WardCunningham

When dealing with the 'veteran' programmers that I work with, (not military veterans) the concepts of OO are completely foreign. Trying to advance to that level in one step is difficult. Since they can understand the benefits of file management as opposed to program or object management, files become the first step.

Many programmers lack the ability to generalize in the way that you describe. Many find it difficult to know how much functionality an object should have. Frequently, you find many almost duplicate objects, each with it's own idiosyncrasy, and having a tendency towards redundancy. This obviously causes increased maintenance and wreaks havoc with the new employee learning curve.

You, very eloquently, define long term maintenance. The balance you describe will often tilt towards the simplistic approach rather than the abstract. Partly because of lack of sufficient understanding of abstraction, some because of time constraints as I point out in ProgrammersAreWriters and partly because of laziness or lack of enforced standards (poor management, personal or otherwise).

What you seem to be attempting to describe is the PerpetualSystem. One that has no life cycle because of its ability to adapt to the ever changing world around it. Eventually the sheer magnitude of the changes that are required, over time, will cause paradoxes that will decay the relationship to the reality defined. OK, I DO believe entropy is a reality.

So, I am accepting system demise, for now, and submit that regardless of the method used as we discuss here, the crux is; the more acute your ability to generalize, analyze, and define in abstraction at the beginning of a project, the better the results of your labors are. This requires a broader base of knowledge and a keen ability to learn, anticipate and even conjecture successfully.

--BillMeecham

So what makes the rules last longer than the code that interprets them? What protects the rules from paradox?

We could stop government regulation, halt all competition, freeze the capricious desires of our marketing types, halt all engineering changes or stop time. Your point is well taken. Nothing really protects the rules from the same fate, but changing rules is faster and easier in files. In addition, many developers tend to spend more time with file relationships and abstractions than with code specification which should result in better definition of rules and relationships of the files, especially using CASE tools. Why bury rules with the interpretations? Especially when different interpretations can apply to the same rules?

---BillMeecham

Part of the magic of defining the rules in the files is determining which elements are business rules, and which elements are implementation strictures. When this has been done perfectly, the code will have the longest life before it needs re-writing, as every appropriate element which is feasible to put into a file can be modified without changing the program.

This can especially be helpful in environments where it requires several days worth of bureaucratic proceedures to implement a 10 second code change, but it takes no special authorization to change a configuration file. I happened to work in a project like that, where the code was written in an interpreted language, and the difference between a configuration file and a code file was basically a filename (although there were people who would keep you from making your entire program in a .cfg file, and saying it was all configuration. Not to mention the language had two types of files, and the .cfg file couldn't hold things for the other type.) Did we think BusinessRulesBelongInFiles? You bet we did. Occasionally, one of my coworkers would save several weeks' time in just a few days because of it.

Some business rules don't belong in files. For example, if you are writing proprietary code for intel, it would not be worthwhile to put the company name into a file. The company name has no real significant chance that it will change. However, if the software is for Joe's Microsoft-bait Startup Company, the company name may very well change soon. Another example would be a rule which is tied to an implementation detail. If your code only implements TCP/IP communication (communication being strictly required for operation), you don't make a configuration file option which enables TCP/IP. After all, YouArentGonnaNeedIt.

---EdGrimm