Mike-O-Matic

So the other day I had a comment on one of my articles from Kenneth Downs over at Secure Data Software.  Intrigued, I headed over to his blog and found a great article called “Minimize Code, Maximize Data.”

He uses an example of a magazine delivery operation and shows two ways that the same problem could be solved.  The data centric way involved having a table of business rules which contained all of the “magic numbers” and precedence used in the program’s main algorithm.  The application part of the program basically iterated over these rules and applied them to the input data.  The application centric way (which he pulled from a real-life implementation he had maintained) made extensive use of conditionals to achieve the same outcome.  He then contrasted the two:

We can see this in the example above for the regulation program. The data-centric solution is basically one loop nested inside of another with the core operation occurring on the inside. The code-centric solution, which I mentioned we are afraid to touch, is full of conditionals and branches that make it dangerous to mess with for fear of causing unintended side-effects. The original programmer could probably do anything with it, everybody else is reduced to doing nothing.

The problem becomes more exaggerated as time goes on. As programs mature, their original simplicity is enhanced to handle more sophisticated edge cases and exceptions. As this process continues, many of these sophisticated edge cases and exceptions will be mutually exclusive or will interact in subtle ways. When this happens the code-centric program becomes increasingly difficult to understand and keep correct, as the layering of conditionals and branches and interdependencies makes it harder and harder to eliminate unwanted side effects. The data-centric solution on the other hand, while still becoming more difficult, is reduced to simply making sure that the tables provide the correct options for the code, and the code remains a matter of scanning the rules, picking precedence, and executing them.

I believe this last point is the one most often missed by the application code crowd:

All new code is elegant.  Time is what makes it kludgy.

Ok, that first part might not always be true; I know plenty of codebases that start out ugly.  But the point is that their starting point is as pretty as it is ever going to get.  A large part of the appeal of using a new application framework is that you get to write it all over again, knowing what you know now.  Of course you won’t make the same mistakes!  Eventually, though, that code will also be legacy, and will turn ugly as the business changes and new things are bolted on the side that weren’t anticipated during the Great Migration.

The only way out of this crazy cycle is meta-programming at the data level; building systems that are self-aware and responsive to changes in data rather than code.  This was my goal in building CodaServer:  To create a platform that provides richer metadata and workflow control than standard database systems for the particular problem area of form-based business applications.

Minimize code, maximize data.  I think I have a new mantra.

Til next time.

Subscribe to this Blog!