Tuesday, April 1, 2008

Optimistic vs. Pessimistic Design: Which one do you practice?

Lately, I've been noticing a trend in some of the object-relational mapping (ORM) tools in the market place, and the pattern that's emerging is interesting, to say the least.

In general, their feature sets seem to fall into one of these categories:

Pessimistic Design - The designers don't know which features their users will actually use, so they decide to implement nearly *every* possible mapping feature and then leave the end-user to decide how to use their ORM. This approach gives the broadest amount of features but sacrifices simplicity for documentation.

Optimistic Design - The designers assume that you're only going to use 20% of its functionality and implement 80% of the features that would be used in 100% of the mapping cases. They provide you with a general framework for the mapping and the change tracking, and they leave it to you (as the end user) to customize it to your needs. This approach makes the ORM easy to use, but the tradeoff is that it only implements a minimal feature set. The upside to this is that the code is so easy to use that it requires little to no documentation at all. It's practically self-documenting code.

From what I've seen so far, a lot of ORM implement pessimistic design, but very few actually implement the optimistic approach. Do the pessimistic designers assume that their end-users are incapable of implementing their own features, or is an optimistic approach too minimalistic to be useful at all?

With this in mind, it's quite tempting for me to write an ORM that uses an optimistic design approach. There might be some value in having an ORM that lets you do your job in a few minutes without having to sift through dozens of pages of tutorials. I'm a big pundit for large feature sets, but in the end, there's no substitute for pure simplicity.


  1. Hi

    Great idea of giving a comparitive ideas in your blog on such topics... i liked the post.

  2. Philip, Do you by chance still have the code for your Tahogen project laying around?

  3. Hi Simply,

    The code for TaHoGen v4 has been lost for quite a while now. The only version that I have is an unreleased (and undocumented) version, which is version 5. If you want to hack away at it, I can license it under the LGPL and you could probably make a quick and dirty WinForms client for it. How does that sound?

  4. Sound good to me :). I am writing a simple add in which generate field from property that use template. So you can generate a multiple property with similar bodies. Right now it's functional and working but I would rather follow some convention for template design so I can expand the project as needed and Tahogen seem like the perfect plug. If I can figure it out that is!

    P.S. I can send you the code if you want to take a look. I am going to open source once I can get it a better shape where it's easier for people to write plug in for it.

  5. Hi,
    We used Pessimistic design for our mapper: NPersist (PuzzleFramework).

    And maybe more so than any other mapper, NP supports a tryckload of features.

    However, in retrospect this was a very bad decision.

    Because the users are presented with an API that is so huge that they have no idea where to start, or what parts of the API are relevant to their specific usecase.



Ratings by outbrain