Programming languages usually have an object model. Programmers tend to think in the object model of one or more languages they prefer, and sometimes have trouble switching mental models. The difficulty of switching models is one reason why frameworks such as the Google Web Toolkit exist -- they let programmers work with a mental model they are used to (in this case Java) and generate code using a different, less familiar model (in this case JavaScript).

Programmers spend a lot of time arguing about which mental model is best. I think this question is unanswerable in the general case, but I want to propose a new way of thinking about it: the object model tax. The object model tax is the drag that an object model introduces to some other layer of your architecture. This drag can take the form of:

• missing features (we can't build that using our model)
• programmer confusion (misunderstandings of the object model that lead to trouble in higher layers)
• bugs (things that do not work as expected because of quirks in the underlying model)

The object model tax is very annoying because it bites you again and again. If there is something about your object model that causes problems, these problem may occur again and again in different tiers of your enterprise application. Also, the object model tax, when it is noticed at all, is usually seen as a defect of the higher layer where it manifests. (For example, programmers report a problem with an MVC framework that stems from an underlying language issue.)

To make this specific, I spent an hour this morning reading through the FAQs for two technologies we use at Relevance: the Hibernate FAQ (several pages linked from here) and the Rails FAQ. I was looking for evidence of the "object model tax" -- Hibernate problems that were really Java problems, and Rails problems that were really Ruby problems. Here's what I found:

• The Hibernate FAQ dealt with five issues that were problems with the Java object model, and four more issues that were partially object model issues, or exacerbated by them.
• The Rails FAQ had zero issues that were problems with the Ruby object model.

(I am not going to post the breakdown, at least yet, because doing it is a good exercise, and you might come up with different numbers.)

What does this mean? I am not sure. There are lots of other factors to consider:

• The Hibernate FAQs are a better, more comprehensive document than the Rails one. Since the FAQs are different, maybe a better comparison would analyze bug reports or mailing list traffic.
• The proportional number of object model tax entries is small (the Hibernate FAQ has well over 100 total entries). However, their impact may be larger than this, because I bet some of the issues recur in other libraries, and in other layers of the enterprise stack.

Is anybody aware of any more detailed analysis along these lines?