When I say, “Documentation,” how do you react? Probably with one of these: Bleh. A drag. Who reads it? The code is self documenting. Or my favorite: It’s intuitively obvious to the most casual observer.
This morning, I ran across Slashdot’s article, Five AJAX Frameworks Reviewed
Dr. Dobb’s Journal reviews 5 AJAX frameworks:… [the] reviewers… eventually settled on the Yahoo! User Interface Library.
This piqued my interest because I had to make a similar review, and consequent decision, seven months ago.
Let me be perfectly clear. I am not professing that my decision-making process is appropriate for all situations. Specifically, I am not even suggesting that it would have been right for the T. Rowe Price project which formed the basis for the Dr. Dobb’s article.
After reading the blurb in Slashdot, I was initially gratified to see it support my own framework decision: Yahoo! User Interface Library. Then I realized that there is something much more interesting operating here. Turner and Wang used a much more exhaustive, time consuming, and expensive evaluation process than I did. My method required one person to invest about about two hours. But both they and I arrived at the same point.
Here is my thought process:
- I decided that my project required a good user interface, ease of programming, and an expectation of successful results (no dead ends). The project did not require any bleeding edge stuff; it just had to work well for the end-user.
- A quick bit of Googling led me to four possible toolkits which seemed to have wide acceptance.
- All four frameworks had been used to build and deploy real web sites so I knew that, technically speaking, all four “worked.”
- Just one of the four, YUI, included excellent documentation with code examples.
- Using the documentation and code examples, I was able to have a prototype of the key component of my project up and running in about an hour.
My experience with the last step gave me the confidence to select YUI and move into development with it. Every time I hit a hiccough while writing the code, the YUI documentation came to the rescue. The project (Memory Lane Designs) was completed without mishap and works well.
The key difference between Turner and Wang’s evaluation technique and my own is simple: I skipped the technical evaluation. The existence of the Yahoo! web site (and several other YUI-based sites) was sufficient for me. I felt no need to spend any time actually writing code to “see if it worked.” I looked only for the differentiators between the toolkits and the YUI documentation immediately leaped to the fore.
I bumped into a somewhat related decision process recently. A friend was evaluating Zend’s IDE and ActiveState’s Komodo IDE. He was spending hours flipping back and forth between the two, digging into the depths of each, trying to pick the right one. I pointed out that the $300 price tag for each was less than the billing rate for the hours he was investing. In other words, it would be significantly less expensive to simply buy one and then buy the other if the initial decision proved to be wrong.
We can get so enamored with an evaluation process that we forget the environment in which the decision is being made. Often there are shortcuts to the right decision which include trusting your gut feelings and trusting the work of others, even if that work is not a rigorous evaluation. Following the shortcuts (intelligently) can save many hours and a ton of dollars.
