Welcome!

Joseph Ottinger

Subscribe to Joseph Ottinger: eMailAlertsEmail Alerts
Get Joseph Ottinger via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Open BlueDragon Developer's Journal

BlueDragon: Article

Too Much Innovation!

Too Much Innovation!

As I look over my choices for various tasks, I'm a little unsettled at how many choices I have, what they do, and how they interoperate. I'm not going to be the one to say that innovation is a bad thing, but too much innovation probably is a bad thing. In software design, it usually means the innovator hasn't looked into appropriate technology enough to know how to use what's available, so a new technology, a new mechanism, is invented. Witness BlueDragon, Vignette StoryServer, Velocity, Cocoon, XTP, CFMX, and JSP: all attempt to solve the same problem, albeit in different ways.

That means that people wanting to generate active content have a lot of choices: master CFML, Vignette's deployment, Velocity's templating syntax, Cocoon and XSL, Resin's XTP, or JSP's various oddities; we can throw in other variants like ATG Dynamo...it goes on and on, even without necessarily leaving Java. (Leave out the Java requirement and it gets worse: PHP, ASP, Tcl, mod_perl, CGI itself, etc.) No longer is generating content a simple decision, and while each technology has strengths and weaknesses, what I've found is that, in general, each "innovation" is a marketing tool, a result of laziness in researching available technology, or an attempt to lock in customers to proprietary mechanisms.

I've used most of these technologies, and I find myself using JSP for presentation, with WebWork providing the activation framework, and my own persistence framework handling data storage. Why? The real reason is because they're the best straight-line solution I see. I don't want to impress my peers with my continued mastery of technology for technology's sake; I want to impress my peers by not needing to trumpet how cool my tools are, by having a system that's under the radar. JSP may not be very impressive, but it gets the job done, and I don't have to spend time teaching people how to use it. WebWork takes a little getting used to for some people, but I've found that the payoff in discussing action invocations is well worth the time it takes. My persistence framework (PortalWizard) is based on simple DAO abstractions. The innovation factor isn't very high, but then again, I'm able to roll up applications that are very flexible in a very short time.

I don't want to focus on presentation. I don't care, really, how my actions are called. Storage is something I only worry about if it's too slow or incorrect. I could try to innovate here; I could try to write a one-size-fits-all solution...but I don't care. I want to get the application working as a whole.

So when do I think you should innovate?

When you have little choice, that's when. The first step should always be investigation, and thorough investigation at that. That means actually using the technology at hand and pushing its limits to make sure it can't do what you need before you start blazing a new trail that won't help anyone in the long run. In general, what I've found is that people don't innovate to improve current technology; they innovate to see their names in lights, to impress others, or simply to get out of doing technology assessment. Innovation shouldn't be horizontal. It should be vertical. An innovation's strength should be so clear to those who understand it that using an alternate technology seems unsound. CGI was nice, for example, but having a way of executing content in the server is a Better Thing, because you don't waste time starting up new processes. This was an innovation, something new, something necessary. Coming up with lateral technologies that don't radically improve things is wasted time. (Consider Velocity, which I don't use - it's a templating mechanism that I should use, because it fills some needs I have in fantastic ways. It's lateral, but the way it renders is very nice. It gets my personal seal of approval.)

Innovation is good; it's even necessary. Nobody claims the technology we have is enough - not fast enough, not good enough, not complete enough. However, unbridled innovation is hurting our industry more than it's helping by breeding underpowered technology and clouding the market's vision. It's time to curb it.

More Stories By Joseph Ottinger

Joseph Ottinger, formerly editor-in-chief of JDJ (2003-4), is a consultant with Fusion Alliance in Indianapolis and is one of the contributors to the OpenSymphony project.

Comments (7) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Robert Wilson 09/03/03 12:25:31 PM EDT

All these technolgies and the JAVA development journal runs on COLDFUSION
I guess that says something. 1 language not JAVA + velocity+ struts + cocoon + weblogic + jboss + ebjs

1 language that it, it works, stop using 5 technolgies to do what 1 can do

Eelco Hillenius 07/03/03 02:33:00 PM EDT

It's interesting to read that the drive behind the creation of Velocity was the licence. When I migrated from Webmacro to Velocity some years ago, it was because back then Webmacro had (amongst other flaws) bad error reporting. Velocity was a better template engine.

Keats Kirsch 06/20/03 11:56:00 AM EDT

... Model 2 paradigm, followed by Taglibs, and now an expression language (JSTL-EL). EL is remarkably similar to the WebMacro syntax that many of us have been using for years (although still not as nice).

Velocity was created as a clean-room re-implementation of WebMacro, not because of technology issues, but rather because of dissention over the GPL license. Although WM was eventually offered under an Apache-style license, the die had been cast and the two groups were unable to coalesce. Interestingly, a sort of friendly competition has arisen between the two camps, which has arguably strengthened both products.

Anyway, I do not think there can be too much innovation, just not enough good tools to sort through them all. Maybe someone reading this can innovate in this area.

Keats Kirsch 06/20/03 11:47:00 AM EDT

there does not seem to be an agreed upon forum or framework for reliable project evaluations.

I find it interesting that you chose to focus on presentation frameworks, and specifically Velocity. A bit of history might be illuminating in this case. Before Velocity there was (and still is) the WebMacro project (of which I am a developer). WebMacro was developed well before 1.0 release of JSP, and was largely a response to the deficiencies in proposed spec. Over time JSP has morphed in an attempt to overcome some of those deficiencies, first with the

Keats Kirsch 06/20/03 11:46:00 AM EDT

...

Keats Kirsch 06/20/03 11:45:00 AM EDT

... not always an easy call as to whether an existing technology is good enough. There are issues of usability, quality, support, licensing, costs, extensibility, etc.

Sometimes evaluating all the options can be more costly than rolling you own solution. This is a major issue in the open source community

Keats Kirsch 06/20/03 10:30:00 AM EDT

While I appreciate your intent to be provocative, I think your column has missed many crucial points. Obviously one needs to look for a suitable existing solution before launching a project, and everyone knows that developers have a tendency to eschew NIH (not invented here) code. But it