3 ms·

Perhaps this could be retitled "Having cake and eating it too: No good options." Big companies want technologies they can invest in that will remain stable and

Perhaps this could be retitled "Having cake and eating it too: No good options." Big companies want technologies they can invest in that will remain stable and supported for a decade or more. Hell, many of them are upset that XP isn't being supported for longer than that. If as a big company you had been a leader and built a web-based app in, say, 2005, it would most likely be a mess of hand-built DOM libraries that sniffed for specific browsers and most likely were wired to IE6 or IE7 (remember, jQuery didn't even exist yet). The "good options" that corps are choosing to use today mainly involve forcing newer versions of Internet Explorer into IE7 or IE5-Quirks mode so they don't have to lift a finger to change that festering pile of custom JavaScript. I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. But that's what they've demanded of the last generation of apps they built.

bradleyjg 13y ago
> I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. Perhaps not, but there probably should be. A lot of LoB applications don't really need to keep up so to speak. Employees learn how to use them, and they accomplish whatever business process goal they are supposed to accomplish. Yes maybe they look or feel terribly old fashioned (curses anyone?) but as long as they get the job done, why should they need to be re-written every 10 years at considerable expense and risk?
Silhouette 13y ago
I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. I think you're making an implicit assumption that a LoB application must be built with a single technology. The recent fast pace of technology development has demonstrated that specifics come and go, but foundations can remain stable for much longer. Data portability matters more than code portability. Open formats matter more than open source. Communication protocols matter more than whatever is on either end of them. If I were trying to implement a major LoB application with reasonable longevity today, I'd go back to basics and plan the software architecture with that goal in mind. Ideas like modular design and separating interface from implementation might not be trendy in a world of web frameworks and "living standards" and processes that are described as "Agile" but really just mean not bothering to plan anything properly. However, those basic principles are as valuable today as they ever were. There is no reason an LoB application using a SQL-based data store running on Linux servers and accessible using tried and tested mechanisms like sockets shouldn't easily remain viable for decades. Probably the most you'll ever have to do is upgrade some front-end technologies to keep up with whatever devices and software platforms your people use to access the system, but that's easy. The problem with a lot of these legacy intranet applications that have relied on successive generations of proprietary browser plug-ins isn't the dependence on the plug-ins themselves, it is that they didn't really have that kind of clean separation of responsibilities. Business logic was coded up in the front-end, so when the plug-in became obsolete, a core part of the application's logic was left in limbo. Communication was done by sending custom formats over home-grown protocols, so when new technologies came along, all of these formats and protocols had to be reimplemented from scratch and often without a proper spec. It's not like it's ever been a secret that these tactics were likely to cause maintenance problems sooner or later. The people who planned ahead still have in-house applications that work just fine. Hopefully the people who didn't will at least learn from their mistakes and know better next time.
derefr 13y ago
I'm pretty sure curses-based form "GUIs" delivered over terminal connections (now, terminal emulators) have survived the last ten years, and will survive the next. That's what you'll see carrying on, just as it has since the 1980s, at airports and banks.

bradleyjg 13y ago

> I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. Perhaps not, but there probably should be. A lot of LoB applications don't really need to keep up so to speak. Employees learn how to use them, and they accomplish whatever business process goal they are supposed to accomplish. Yes maybe they look or feel terribly old fashioned (curses anyone?) but as long as they get the job done, why should they need to be re-written every 10 years at considerable expense and risk?

Silhouette 13y ago

I'm not convinced that any technology exists today that will be so set-it-and-forget-it wonderful that companies should plan to build it now and leave it the hell alone for a decade. I think you're making an implicit assumption that a LoB application must be built with a single technology. The recent fast pace of technology development has demonstrated that specifics come and go, but foundations can remain stable for much longer. Data portability matters more than code portability. Open formats matter more than open source. Communication protocols matter more than whatever is on either end of them. If I were trying to implement a major LoB application with reasonable longevity today, I'd go back to basics and plan the software architecture with that goal in mind. Ideas like modular design and separating interface from implementation might not be trendy in a world of web frameworks and "living standards" and processes that are described as "Agile" but really just mean not bothering to plan anything properly. However, those basic principles are as valuable today as they ever were. There is no reason an LoB application using a SQL-based data store running on Linux servers and accessible using tried and tested mechanisms like sockets shouldn't easily remain viable for decades. Probably the most you'll ever have to do is upgrade some front-end technologies to keep up with whatever devices and software platforms your people use to access the system, but that's easy. The problem with a lot of these legacy intranet applications that have relied on successive generations of proprietary browser plug-ins isn't the dependence on the plug-ins themselves, it is that they didn't really have that kind of clean separation of responsibilities. Business logic was coded up in the front-end, so when the plug-in became obsolete, a core part of the application's logic was left in limbo. Communication was done by sending custom formats over home-grown protocols, so when new technologies came along, all of these formats and protocols had to be reimplemented from scratch and often without a proper spec. It's not like it's ever been a secret that these tactics were likely to cause maintenance problems sooner or later. The people who planned ahead still have in-house applications that work just fine. Hopefully the people who didn't will at least learn from their mistakes and know better next time.

derefr 13y ago

I'm pretty sure curses-based form "GUIs" delivered over terminal connections (now, terminal emulators) have survived the last ten years, and will survive the next. That's what you'll see carrying on, just as it has since the 1980s, at airports and banks.