How many times have you been working on implementing, unsuccessfully, a feature in your application which relies on a framework, container, or some other indirection layer? You’ve studied the specifications, memorised the API and you’re following the developers guide which are all telling you that what you are trying to implement is taken care of, but it still does not work!
While recently working on a really simple application feature using ADF data model validation I had just this experience. The feature just did not work and there was nothing in the logs to indicate what the problem was or that there was even a problem. Admittedly, I was using an internal development build, so it would not have been a fully tested version. I checked, and double checked everything, the documentation, searched through forums and blogs, trying to find out what I was doing wrong.
By the way, while searching I did come across an interesting blog about ADF bugs and workarounds. Steve Muench‘s Dive into ADF blog is probably the most comprehensive on ADF features though.
It turned out I wasn’t doing anything wrong but I only found this out when a colleague suggested I check the bugs database. And there it was! The exact scenario I was trying to implement had a bug against it. What a relief, because I thought I was missing or skipping over something really obvious and fundamental and that’s why it wasn’t working for me. Better still, the defect was marked as closed so it will be available in the next internal developers build.
This got me thinking about all the documentation sources I had been to and how useful it would be to have a cross reference between the structured and unstructured text of developer guides, API, forums, blogs and bug databases. Isn’t that what search engines are for?