At the moment I am re-emerging from a long session of a well known IT
adventure game known as "catch the randomly recurring problem in the
mission critical system".
Step one in fixing any IT problem is the creation of a test "harness"
which can be used to repeatedly re-create the problem. Once that is in
place, standard scientific methodology takes over. Change things one at
a time until the problem goes away. All other things being equal, the
last thing changed is the source of your problem.
The more distributed, complex and multi-cellular our IT systems become,
the harder it is to create these test harnesses. On numerous occasions
during the debug cycle, I found myself on the Web, chasing down error
messages, reading manuals, reading postings from other developers.
Actually, mostly reading postings from other developers.
Looking back on it, I think it is fair to say that I would not have
solved the problem without the Web. A strong statement I think you will
agree. A statement that begs the question: "what did we do before the
Web? How did complex systems get debugged without it?"
Well, we did. Just as our forefathers survived without antibiotics,
television, Kinkos and chocolate brownies, so too developers of
yesteryear survived without the Web.
I don't think we build systems any better these days than we used to
mind you. It is just that now, thanks to the Web, we have a higher
threshold before we hit information asphyxiation - the point at which
progress is impossible without more information.
These days, thanks to the Web, we have a lot more access to stuff which
means, in turn that we use a lot more stuff. Which, in turn means we
need yet more access to stuff. Vicious circle or progress? You choose.
Personally, I doubt that it would be possible to, say, build a complex
J2EE based system just using the vendor manuals and without using the
Web. The higher information threshold it provides has become an
indispensable tool.
I'm not happy with the word 'information' as I have used in here. The
Web certainly provides raw information in abundance but I think the
critical thing it provides to IT practitioners these days is access to
conversations - not merely raw information. Conversations which, for the
most part, take place from consumer to consumer. Developers talk to each
other, exchange questions and answers. Theories and snake oil solutions
go to and fro. They talk, the rest of us listen.
Returning to my marathon debugging session, here is a rough calculation
of where I spent my debugging time:
Vendor manuals: 10%
Googling: 20%
Reading developer blogs, user mailing lists etc.: 70%
Note the very low percentage of time using the "official" resources from
the vendors of the applications involved.
I solved my problem, not by reading the manual but by lurking in, and
later participating in an electronic conversation about the vendor's
software. A conversation created by consumers.
By coincidence, a UPS parcel arrived today containing a manual for a
vendor's product which happens to be part of system I was debugging last
week. After a quick flick, I threw it in the bin. Why? Because it
contained no useful information that I could not find in more accurate,
more to-the-point form on the Web by reading what other consumers are
saying about the software.
The 70% figure above can roughly be broken down further like this:
RSS feeds: 20%
RSS-only search engines: 20%
Blog surfing: 30%
You are probably surprised how big a role Weblogs and RSS had to play in
my adventures. Me too. As a result of my travels, I now have an
excellent collection of new RSS feeds in my aggregator that keep me
tuned in to ongoing developer conversations about the stuff I was
debugging.
Pretty soon now, I predict we will be asking the question "how did we
every debug software without access to weblogs and RSS feeds?"
