A long time ago I wrote about the software-reuse-paradox which basically says that reuse is achieved by throwing stuff out the door.

The last month I've been poking around in hibernate-land over a smaller personal project that started quite some time ago and only every now and then needs my attention. Back then it sounded like a good idea to use hibernate, today while wondering why I keep fighting with it, I started to discover another software-paradox.

The more ways there are to show you are wrong, in fact the more bugs you can list, the more confidence people will have about you being right.

Or reversed: Providing evidence of stuff working is done through offering (ways to) prove that it is failing.

JUnit tests live in this category. If you write them well they're a whole bunch of statements about when and how your software can/will fail. The more of those you provide, the less the actual result will actually miss out on new use cases.

Public, searchable support-mailinglists and bug-archives do an equal job in a less formal way. Even if they provide no fix or workaround, they tell you that you can stop poking around and even trying with the current release of things.

Of course this developer-self-control (junit) and social network (lists and archives) is, in terms of confidence building no match to the peek/poke behind the scenes that the end-user can perform himself (ego amplified assurance).

Obviously it's this last thing I miss with hibernate. In each problem I face I miss the easy assesment that can help me make the distinction between me being the stupid jackass again, or hibernate not supporting. It doesn't help that hibernate keeps being the only implementation of their own 'standards'. The end result of this is confusion, 'trial and error'-cycles (I hate those) and thus general discontentment. With all those people on the planet raving about hibernate this generally makes me feel rather stupid, right before my ego fighting back with the observation that in all my stupidity I'ld been done with the problem already if I just wrote everything from scratch. Maybe it is just that dreadful 80-20 rule, mixed in with the honest truth about (open source) software that you can (really) only (really) appreciate the works of the 'black-box' if you can easily hold it up against the light and have a look through. Having access to the source in this respect proves to be less interesting then having the time to digest it fully, or even better having been involved from the start.

If ever you wondered why there are soo much frameworks doing the same out there :-)

Anyways, taking the knowledge from the new software-confidence-paradox just laid down, this would suggest that JDO implementations have a brighter future then hibernate just cause one would be able to swap one implementation with another (in any case I (like to) see vague signs of the pendulum swinging back from havoc OR/mapping to some more DIY coding on the basics of something like Spring's JDBCtemplates).

I like to believe it also affirms part of the reasoning behind our REST focus in the architectures of daisy cms and xreporter enabling you to look behind the scenes of distributed programming with a simple wget or standard browser.