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 us= e 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 th= e 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 f= actor 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 templ= ating 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
