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.
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?