Re: Specifying all biz rules in relational data

> My own first principle is this: Code is a non-portable depreciating asset,
> while data is a portable appreciating asset.

It is possible to make code portable (between opertating systems).

> In other words, like diamonds, data is forever, while code is not.

I almost agree. In history data has changed from flat files to hiarchical databases to relational databases. It is not for ever, but almost. But of course programming languages changes much more often than database paradigms.

> My real asset is
> the data, and I can write generators for the language-of-the-month if there
> is a market for it.

This is true for some applications, but not for all. For example, I am working with an application that among other things calculates the salary for employees every month, according to complicated swedish rules and laws. In this case, the calculation algorithms is the read assets, not the data. And I see no possibility to auto-generate this algoriths.

> How do you answer the objection that, no matter how flexible the language,
> once business logic has been coded in that language, it becomes "trapped"
> in a format that can only be "mined" later at great expense, after the
> original programmers have left, the shop has been sold (twice) and the new
> customers have different objectives. Suddenly a hot-shot comes along,
> realizes his/her future depends on planting a new flag on a new mountain,
> and declares the old system "legacy" and begins work on the new one.
> Because the cost of reverse-engineering the system is so high, the asset
> has depreciated completely, its value becomes zero as it is discarded by
> the powers that be for their shiny new system (which will probably have
> half the features and run at half the speed).

I agree fully, but neverless, a lot of business problems can only be solved using procedural coding. Not everything in life is easy.

> 4. This is sufficient to implement all known business information
> situations.
I don't agree.

> Since the GUI is not business rules,

Correct in most situations. Mostly a GUI (in a enterprise application) do CRUD operations on records, with additional data validation. But there are also examples there the GUI has a lot of business rules, for example the control screen for a paper mill etc.

> On another track, you state above, "It is also very important not to
> generate more than absolutely necessary." Can you elaborate more on your
> development philosophy with respect to the role of the stored data, the
> generated code, and the hand-coded elements come together?

If you have all your business rules in some sort of control tables, why do need to generate at all? Your application can read this control tables and create a GUI (or something else) runtime. Of course generated code will have better performance, but once you have generated the code, you need to re-generate if you change your generator. If you don't generate, changes in your application will have effect next time it is started.

/Fredrik Received on Mon Sep 13 2004 - 10:09:36 CEST