Pragmatic Programmers on Designing with Metadata

Bill Venners writes "This week I've published the fourth installment of my interview with Andy Hunt and Dave Thomas, the authors of the best-selling book, The Pragmatic Programmer. In this installment, Dave and Andy talk about their recommended approach to design in which details are pulled out of the code and stored as metadata. This installment of the interview really made me think. Their focus on metadata sounded non-intuitive when I read their book, but in actually talking to them about it, I got the feeling they might be on to something. Check out: Abstraction and Detail."

Comments

Rules, not metadata

[Twylite]

Maybe I've got the wrong idea from the interview, but what was discussed was rules, not metadata.

Business rules are a well known aspect of enterprise software development, especially in light of the many old(er) custom-build systems in which the rules were hard-coded. A business rule is "sales tax is 7%", or "customer pays a 1.5% surcharge is payment is more than 2 days late".

Metadata is a partner and also an opposite to a business rule. Metadata is quite simply "data about data". The fact that the value "7%" is "sales tax" is metadata; but the fact that the current value of the sales tax is 7% is not. The age-old concept of a "data dictionary" is an embodiment of what metadata is.

A rules engine is (rather simply) a powerful extension of the practice of declaring constants for significant literals (which are or could be subject to change); quite often one which allows runtime modification of the value rather than requiring a recompile. Rules engines also tend to provide mechanisms for evaluating compliance with the rule, or performing calculations based on rules.

Bad Summary

[Jerf]

The article simply says: do not encode "known" constants (such as tax levels, etc.) into the code, but put it in an external XML database.

No, that's not what it says. It says do not encode known behavior into the code, but put it in some more easily changed external data source. Also, it might be XML but it can also be in the code, just code structured more like data then code. (I often write code-data like that, writing default keymaps in the language itself, for instance. It's easier then writing a custom parser if you just use the language itself...)

Sales tax is used as an example for the interview, but it goes deeper then that. The other example is much more instructive, with the display of financial numbers. Few programmers instinctively write a "displayMonetaryAmount" function that allows them to make one edit to suddenly display negatives in red; it's much more common to always directly dump the value. "displayMonetaryAmount" is likely to be very simple, almost data-like, and easy to change, rather then changing the code everywhere that displays money, which is virtually impossible to correct.

There's a lot of value in that approach that is missed out on by a lot of programmers.