In The Wiki Wiki Wiki Wiki Wiki Room

I don't think that many people would dispute the success or value of the Wiki. For those of you who have been living in a cave for the past two years, a Wiki is a collaborative document system, environment, or philosophy, depending on who you talk to. While the most famous is Wikipedia, the online, user written encyclopedia, there are zillions of Wikis on the Internet. Most are information repositories of some sort, especially on-line documentation.

The advantage of the Wiki is that it is very easy to write and edit entries. Formatting those entries, while a bit unconventional, is also pretty easy. This yields highly attractive, easy to navigate online documents.

Deploying a Wiki application, such as MediaWiki, the software behind Wikipedia, is also incredibly easy assuming you have a working L/WAMP stack operating. I've worked with all types of collaborative systems including Lotus Notes and a number of knowledgebases, and few are as easy to use as a MediaWIki and none are as easy to install.

Some time ago, I installed and started using a Wiki for tracking storage companies, my bread and butter. That in many ways is a conventional use of a Wiki. Think of it as building an encyclopedia of storage companies. Nothing Earth shattering there.

I also started using my Wiki for development projects. I build my own applications from time to time to provide me something useful, try out technology that people are buzzing about, and simply to amuse myself. On my latest project I used a Wiki to help me to design the application and capture my decisions along the way. What I found was a product managers dream application.

Anyone who has had to build product specs, PRDs, etc. knows what a pain they can be. They are dynamic, require input from lots of often unwilling people, and whole sections usually need to be written by specialists. In other words, they require collaboration, the stock in trade of a Wiki. The same would go with design documents that engineers use.

As time has gone on, I have been able to add and expand sections, eliminate others, and make changes as needed. All without losing the thoughts behind them. As is typical with web applications, you can link to other documents or sections of documents with easy including outside ones. If there were engineers writing the technical design elements, they could simply write them in. If a change occurred to a feature requirement, everyone would know immediately.

Contrast that with the way this is usually done. Dozens of Word documents tossed at the product manager who has to somehow integrate then all without getting something terribly wrong. Playing cut and paste with e-mails and other documents, trying to pull them together into a unified whole but never having a sense of the entire project. Gack! Makes me choke just thinking about it.

Heck, by the end of this, I'll almost have a design manual on how to write this type of application, useful to anyone who would want to do the same in the future. Development and knowledge capture all at once.

This is the killer app for product managers. Using a Wiki, you could pull together requirements documents in half the time and tie them back to the design documents and anything else associated with the product. tech support would love what comes out of this if QA used it. And it cost practically nothing to deploy. The software is free as are most of the infrastructure.

Free and transformative. What could be better.

Same Engine, Different Body

For various reasons I have been writing software again. It's mostly hobbyist stuff or small, useful applications. My TagCloud software has been incredibly useful and was fun to work with. I used to write and design software for a living and it was not nearly as much fun (that's why it's called work folks!).

So, my latest project is a rewrite of an an old travel planning tool that I built in Access years ago. Keeping with my current fascination with modern web-based development, I decided to implement this application as a Java servlet within a Tomcat container. I've been writing Java code since it was new and like many aspects of the language and virtual machine architecture.

One of the big advantages to OO programming is the ability to hack together pre-written chunks of code to build applications quickly. Java makes it very easy to dump in different frameworks for important functions. Need to interface with a database? JDBC makes this easy. Make mine a web server application please. It's easy with the servlet interface.

This advantage also leads to Java's biggest problem: framework and component proliferation. This is most evident when you are building web interfaces. There are all types of competing frameworks and it's easy to get confused. Should I generate the interface as pure HTML/JavaScript from within the servlet? How about using Ruby on Rails, though that means learning yet another language. JavaServer Pages (JSP) might handle some of the static portions of the interface. Is that enough? Should I use a web UI framework? Okay, which one? Struts or JavaServer Faces (JSF)?

It makes my head hurt.

This is the dark side of component and object technology. The things you need to know become so great that you need armies of specialists to write even a simple application. If you don't think this is out of control consider this: Nine years ago, ever thing I needed to know about Java could be found in the two O'Reilly books "Java in a Nutshell, 2nd Edition" and "Java Examples in a Nutshell". At that time they had 11 books altogether about Java, but many rehashed the same subjects. The "Java in a Nutshell" book was only 610 pages long.

Contrast that with what is available today. They O'Reilly web site lists over 125 books on the subject (I got tired of counting) and the 5th edition of "Java in a Nutshell" is listed as having 1252 pages, more than twice the 2nd edition. In 1997, there was one UI choice, the AWT. Now there is still AWT but also Swing, Spring (whcih includes a bunch of other components), the aforementioned JSP, JSF, and Struts, and the Eclipse SWT. Or maybe I could use Ruby on Rails to generate the interface or even JavaScript on Rails. I don't even want to get into all the other extensions, component libraries and frameworks available (J2EE, JavaBeans, AspectJ, JXTA god know what else).

Now if you think this is simply the ravings of a weekend programmer who can't make a decision, consider the poor system architect who has to design a major enterprise application. Not only do they have to evaluate and choose what parts to use but those choices will drive specific costs. Training, books, and time will cost money. Just keeping up with versions and updates could occupy someone full-time. It's job security I suppose.

To be blunt, this is too much of a good thing. Granted, no one wants to have to write all of these parts from scratch. Talk about serious time issues. However, we could do without so much duplication. Do we need Struts and JSF? I'm sure that someone out there is yelling "Yes! By gum we do." and will have a dozen reasons why. Most of those reasons will turn on some minor technical or philosophical issues that matter to only tho a handful of people. I'm sure that some will also argue that it's about choice and choice is good. Maybe, but it's also confusing.

I don't offer a solution here. This probably won't happen with .Net. Microsoft keeps too tight a control on its technology to have this happen. It might also help if the Java community would line up at least the competing technology and pick just one in each group.

In the meantime, I will, like everyone else, make my choices and hope they are the best ones.