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.

Ratings by outbrain