Alan Keefer
Posts: 29
Nickname: akeefer
Registered: Feb, 2007
|
|
Re: Application Longevity
|
Posted: Jun 7, 2007 2:49 PM
|
|
Using a standard solely for the sake of using a standard really only makes sense when it comes to ineroperability: I might hate SOAP, but it's standard enough that exposing a remote API as SOAP instead of via some other, proprietary mechanism makes sense. Other than that, all bets are off, and I think standards should really only be used if the fit the application's needs. JSP and JSF are "standards," but if some other web framework is more appropriate to your development needs you should use it. And if there isn't anything out there that meets your needs, then build something that does. That's not cowboy-coding, it's just common sense.
There's naturally some value in using standards when it comes to the availability of tooling, the ramp-up time for new developers, and maintainability, but those are simply inputs into the equation and not trump cards. Perhaps I'm just being naive, but trying to design now with a future platform migration in mind is insanity: any predictions you attempt to make about what will make future migrations easy are almost guaranteed to be wrong. Thinking a little up front about application longevity and not painting yourself into a corner are always good, but making decisions that cost extra time, effort, and complexity now on the basis of some potential, unknown event 10 years out is just not a good idea. Developers will always complain about the earlier developers and managers will always complain about developers, and that's just kind of something you have to accept; what seemed like a good idea five years ago looks idiotic today, but if you obsess too much about what will look good in five years you'll never get anything useful out the door. Fashion always looks ridiculous in hindsight, and so do technology decisions; maybe you get lucky and create something timeless, but probably not.
I think the Java community in general has a serious problem with fetishizing standards for the sake of standards, as if some idea or piece of code isn't professional or valuable if it hasn't been blessed by some standards committee and given an acronym, and it really gives the whole language and community a bad rap. Most of the innovation in any language comes from outside the standards, and you should always use the right tool for the job whether or not it's been standardized.
|
|
Previous Topic
