There's a J2EE tie-in. I promise.
A fellow user mentioned something the other day about using libraries in Java. He said, and I paraphrase, that he simply didn't feel comfortable using a library if it couldn't be explained in one page. For the sake of argument, I'll assume he didn't mean one 400K page.
I'm not sure I wholly agree with his statement, but his point is well taken. When I look for a tool, I want that tool to have a very clear purpose and documentation. A name should be an easily associated mnemonic, perhaps a direct tie-in to purpose, and the documentation should allow the user to quickly get a sense of not only what the product does, but how and why, too.
Some examples of good product names, in my opinion: EXML, RSSLibJ, commons-httpclient. Some bad ones: commons-digester, maven, blissed. I'm not saying the ones named well are great products; I have my reservations about them, even the one I co-authored. Nor am I saying the products whose names I dislike are not good products: I'm simply saying that their names don't help you associate the products with what they're for.
I think virtually everyone understands the problem of good documentation: you'd be hard-pressed to find any programmer who hasn't gone to some project's documentation, read for a while, and come away scratching her head with no clearer picture than she had before. Maybe that's happened with popular projects - I know that some of my own general-purpose projects are still "blessed" with obscure docs.
I'm hardly exempt from the problem of documentation. I'm a fairly abstract thinker in a lot of ways, and a "big thinker," so I have a tendency to solve problems in abstract ways, making things harder to explain. It's happened a number of times in my career that I've intuitively architected a solution and been unable to explain it to the teams around me... until later, when the problems my solution addressed manifested themselves. (True story: one team refused to take my solution as anything more than the rantings of a mad hatter, and chose to use a simpler, more straightforward architecture. Months later, when the localization problem I was trying to solve became apparent, they - and I - realized that I'd been on the right track all along, and we ended up going back to the plan I'd suggested first. I've never had a deserved reputation as a great communicator.)
My difficulties are directly related to my mode of thought because I tend to be a bit scattered and draw technical material from a lot of sources related to the humanities. I can shrug and say, with a light sprinkling of seriousness, that I'm an artiste and can't be held to reasonable expectations. That said, I don't see that same scattershot approach in every project, so why do so many of them have poor or unclear documentation? We're nominally engineers; why can't we approach our solutions from an engineer's cut-and-dry viewpoint and say, "Here's the problem; here's a solution; here's why this solution was chosen; here's how to make it go"?
