Will the upgrades and conversions ever end? Will we ever get any work done again?
Those are just two of the questions Mike Jdmmer, a contract Webmaster for Ohio-based Katson Industries Corp., is asking. (The third, if you must know, is, “Am I being paid for this interview?”)
“For months, we had struggled putting together a secured Web site to accept online orders for our sump pump replacement valve assemblies and seals,” Jdmmer says. “It wasn’t a glamorous site; it didn’t need to be.”
He says the project has grown from person weeks to person months. And worse, “We’ve had to bring in an XML guru, and there is still no reason to suspect the new Schockwave-enhanced welcome panel and streaming video will sell any more billet bypass valves.”
Katson Industries is not just another example of a company that needs to focus more on its core business. Its latest IT struggle, this one with XML, epitomizes many of the problems organizations are facing in their never-ending battle to keep in step with the moving target of technology.
“The sooner we all settle on a technology, the sooner we can be more productive,” says Jason Brei, who’s not an industry analyst, but as assistant manager of the Sunnyvale Galleria’s Pretzel Town, he has served many pundits his lightly-salted snacks.
Brei’s point, though quantitatively unsubstantiated, makes a lot of sense. Consider that in today’s job market there’s a recruiting feeding frenzy–a shortage of talent and a great demand–for contemporary technologies like Java, XML, and Oracle, while the unemployment rate for over-fifty ITers is, by some accounts, as high as 17%. The popular view is that older ITers lack the skills necessary to make them competitive in today’s organizations. But the truth, according to Brei, is that technology is changing so quickly everyone’s skills are in jeopardy of going the way of the dodo at some point–sooner, not later–in their careers.
“Continuous training is one solution,” Katson’s Jdmmer says, “if you like the idea of chasing your tail. But wouldn’t it be more productive to have people working on solutions rather than having them offsite learning a new technology that may be stale before their expense report is approved? In less than a decade, we’ve gone through C, C++, and Java. And Microsoft’s latest introduction, C#, claims to trump all that came before it. When will it end?”
To put things in perspective, what veteran audiophile hasn’t spent more time converting his “Grateful Dead” vinyl to reel-to-reel, then to 8-track tape, then to cassettes, then to DAT, to CD, to Minidisks, to MP3s–than actually enjoying the music?
Some technologies will, by market forces, constantly change (if you bought a Betamax or have invested in a Kodak disk camera and can’t even get a bid to cover postage for them on eBay, raise your hand). Some things by necessity will change. For example, in retrospect, nicotine-enhanced candy cigarettes and jujubes with fluoride were bad ideas. Still, many things change merely for the sake of change. What, for instance, was so wrong with COBOL that a few releases (OK, several releases) couldn’t keep it competitive with Java?
Well, maybe we don’t want to regress back to the days when COBOL was the latest and greatest, but neither do we want to necessarily embrace every new language that comes along…unless, of course, you like recursion. Unless, of course, you like recursion. Unless, of course, you like recursion.
|CIO to Project Manager:|
CIO: You told me this technology would outlast the corporation.
Project Manager: Well, the company’s fiscal condition didn’t look so good back then.
No one is saying XML is a bad language (no one except those developers working on XML++), but why can’t we just settle on one language and build on it? Think about that for a minute–a unilanguage that runs on any platform and any network. One language that CS students could learn and veterans could refine to do anything. No more misspent hours pursuing the latest technology and perhaps even betting the farm on one destined for obsolescence (anyone running CP/M these days?).
Such a language would have a relatively simple, yet powerful, function set and self-documenting syntax. Consider the following code segment written in the proposed Visual Esperanto++ (RFC 66739), which can run as seamlessly on a mainframe as it can on a Win98 (oops, make that NT, no, make that W2K, wait, this just in, make that WinMe) workstation; 100% portable whether it’s downloaded to Netscape 7.3 (build 8.047) for the Nintendo Gameboy or Internet Explorer 7.1 for your universal TV remote control.
|Intern to Team Leader:|
Intern: Why are we converting this app to Java?
Team Leader: I don’t know.
Intern: Didn’t you just spend six months converting it from Visual Basic to C++?
Team Leader: I guess.
Intern: What sense does that make, then? Where’s the ROI?
Team Leader: I dunno.
Intern: Hey, Tom, sorry to ask so many questions.
Team Leader: That’s OK, Diane, how’re you supposed to learn how software is developed if you don’t ask questions?
Of course, some of the actual implementation of the functions will have to be fleshed-out, but you get the idea. One language for all of IT–for all time.
Can you see the possibilities? More time coding; less time porting and scaling. More development. Less impediment. Progress, not “quiesce.” In short, a lot more available time for important things, such as your company’s name-the-new-mission-statement contest.
It’ll take a lot of work to get there. And cooperation. Vendors will have to learn to get along–there can be no proprietary “extensions” that lend themselves to offshoot languages. But the payoff to such a revolutionary effort would be significant; imagine no staffing shortages. Developers, like fine wine, would get better, not just older, with age. And projects would be complete before before they’re obsolete. What a wonderful world it could be. //
End Note: Microsoft Notepad was used in the development of this column because it still works just fine!