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"?

I don't have a clear answer. If I did, I'm sure my own wider-scoped projects would have better documentation. I can just use that programmer's statement about a one-page document as a guide limning my path, and as a measuring stick that I can hold my own documents up to. Is the document as short as it can be? Does the document have a premise? Is it directly answering that premise? If I was reading it without foreknowledge of the subject matter, would I be able to understand what the document was trying to say? Would it contain useful references to other documents to give me the bits outside of the basic premise?

I know that I sound like a professor of language, asking those who write to approach the task as if it were a craft. I imagine many are shuddering with bad memories of college essays, thinking you'd gotten away from crafting term papers and theses. Well, you have - I don't ask anyone to write a doctorate-level paper when all you are trying to do is tell someone how to write a Webwork interceptor. However, the basic skills still apply - who, what, when, where, why, and how. Without these being at the very least addressed and discarded, a document will always sound vaguely unfocused, and that's torture for your readers.

By now, you're reading this wondering why a Java Enterprise editor is lecturing on basic documentation skills. I promised a tie-in, and here it is: recently, Tod Nielsen (executive VP of BEA) wrote a missive I disagreed with about the future of J2EE being predicated on clarity and simplicity. I saw his point, but I think he's reacting to the lack of effective writing on the industry's part. We write complex systems and don't bother to explain them in simple ways, so we're left perceiving their complexity, and people who aren't interested in complexity for complexity's sake just don't care. Donald Knuth imagined literate programs as programs that you would read, sitting by a fire with a glass of something enjoyable handy. If architectures were designed with this kind of perusal in mind, think of the future time spent maintaining them: it'd be a joy, comparatively, and Mr. Nielsen's plea for a simpler API would sit unneeded.

We need to work on our communications, all of them. Our systems, regardless of their underpinnings, need to be explained in simple, clear terms. Anything less dooms us to the amateurism of which our industrial competitors accuse us.

Let's do better.