Perhaps you are like me. You heard the term "Web 2.0" and thought it was the most ridiculous catch-phrase you had heard to date. Go ahead, "Google" it. It is the shining stellar example proving that MIS is no longer about information via technology; its all about fashion and status. Just take a look at the definition provided by, Tim O'Reilly (left). Tim, consumes 5 pages trying to define "Web 2.0". The Wikipedia definition uses the word "perceived". Perceived? The use of this word is quite telling. One uses this word when reality may differ from the connotation or more accurately, the reader's reality (connotation) likely depends on the individual.

The various authors first explain that Web 2.0 does not refer to a 2.0 version of the internet. Then they go on to discuss the various technologies dancing around the fact that these technologies existed before the term Web 2.0 was invented. Ajax is always mentioned, but it is acknowledged to suffer from the same chronological problem in that it is just a "fashionable" way to refer to the use of pre-existing technology. I am going to go out on a limb here and claim there is no definition of Web 2.0. I feel comfortable doing this because the attempts to date are wordy and convoluted. If it takes you 5 pages to define a term (you helped invent), then the value of a definition comes in to question. The whole thing begins to look more like an art appreciation exercise (fashion).

Despite the fact that there is no consensus on the meaning of "Web 2.0", you can check a URL to see if it is Web 2.0. Hey, at least the authors admit it is in the beta stage. This is somewhat off topic but I found it ironic and funny. According to this web site, if a site uses CSS, PHP and denies the existence of Rocky V, it stands a better chance of being considered a Web 2.0 site. Hilarious!

How much JavaScript have you written to give the user the feeling of a desktop application on the browser? I, for one, am sick of trying to turn a stateless, thin client, programming paradigm, into a rich stateful fat client experience. Now I am not talking about true e-commerce web sites. Of course, web based businesses, cannot develop distribute and require the use of a specialized application to make purchases. What I am referring to is your CIO of a typical brick and mortar business being sold on a bunch buzzwords. Think about your last high-tech purchase. How much did it improve your life? And how important was it to get something "cool", something you might stand a reasonable chance of impressing your friends with? Chances are that it did not improve your quality of life all that much (think cellphone) and you probably spent more than was wise for a bunch of bells and whistles. Likewise, why develop a standard client-server application using MFC when you can sprinkle your executive briefing with, AJAX, J2EE, EJB, XML and the all important "platform independent". That last one is real important to most businesses. Employees just do not know what's going to be on their desks come Monday morning. And those kids in the data center are forever swapping out application servers and RDBMS engines. Doesn't everyone just love the ever rotating configuration of hardware and software they have have to use to get their jobs done? What's that? Your still running on a 1GHz Pentium with Windows and Office 2003 and have been for the last 4 years. You mean your databases are still running on Oracle and you haven't had 5 major data migrations in as many years, from Oracle, to DB2, to MySQL, to Informix and back to Oracle?

Sarcasm is a harsh way to make a point but the situation calls for harsh tactics. Things have gotten so out of hand. For instance, I have been building, at a cost of about 1.5 man-years, a web based AJAX and Hibernate fueled speed demon for 4-5 employees to use maybe 4-5 time per fiscal year. We had to use AJAX because of the size of the data sets and the computational costs thereof. The thing is, the more AJAX one writes, the more one begins to realize that you have moved back to the traditional GUI event driven model of the early 1990s but you are trying to use the equivalent of assembly language, hand-crafting all of your own tools.

This "fashionable" aspect of programming is not a recent phenomenon. Take CORBA for example. It was all the rage in the mid '90s. The company I worked for developed products for networked applications and wanted to investigate integrating CORBA into the list of supported paradigms by developing a small application to allow an administrator to control the product, running remotely on one of 4 different operating systems: AIX, HPUX, FTX, and VOS. My manager elected himself the GUI implementor. I had the challenge of writing the various versions of the back-end processes. The only target platform ever mentioned for the GUI was Intel and Windows. The year was 1996. Java was the new darling, the new item no fashionable resume should be without. Given the heterogeneous nature of the back-end servers and the homogeneous GUI client, what languages were used for each and why? Well, they decided C++ would be used for the multiple platform server processes (for still as yet unknown nefarious reasons) and, for platform independence, Java would be utilized to implement the GUI with its target of a single platform. Why, because a marketing troll wanted to put Java on a glossy brochure and because the manager lacked the strength to do the right thing and was just looking to pad his resume. Now he works for Microsoft. It was hilarious. I watched these guys in meetings when asked why Java was being used for the single target platform client. The hilarious part was the other person's reaction, usually a double take, and the sedate look on the Java proponent as though they had just uttered some obvious truth. It was classic "Dilbert" material.

Recently, I had the pleasure of writing a traditional client/server application using Eclipse SWT. Funny, it was just like the JavaScript but without all the hassles of writing industrial strength applications in a scripting language. It was truly striking, the ease with which I could implement the same behavior that might take one or two days to get perfect in a web application. If you have past experience writing MFC or SWT applications but have recently been sequestered to web applications, go back and take your worst web scenario and re-implement it with the traditional GUI technology. I think you will be reminded that there really are different tools for different tasks and that these tools exist for a reason.