ack when we did real programming, something positive could always be learned anytime we made a mistake. But that isn't necessarily the case now.
I came to this conclusion recently while attempting to build a Web page. After selecting the ugliest possible background by accident,
I attempted to see if I could change it to something less irritating. I pulled the menus and made all the clicks that appeared to be necessary as the software benignly accepted my masterful mouse movements and key strokes. I then attempted to view the results of my actions. This wasn't easy, because the package is dependent on somebody else's browser to display the actual pages. After a save, a build, a link, and an Alt/Tab (ain't multitasking wonderful?) I observed that nothing had happened.
My first thought was that this wouldn't have happened in the old days. Back then, this program would have rejected my advances instantly with an enigmatic error code, a series
of disconcerting light flashes or, worst of all, the dreaded ABEND (abnormal end) message. Programming in those days was a discipline, not an art. The systems we built-which are now called "legacy systems" by those who don't want to be associated with them-were not constructed for nonsensical programming errors (though some maintain they weren't built for routine user errors, either).
I cringe at the use of the word "legacy" when connected with those mainframe wonders I helped design and implement, but I will not apologize for them. They accomplished their purpose, which was improving productivity. (Translation: They allowed the companies that used them to cut people from the payroll. I don't apologize for that, either-because, in my observation, the computing industry now employs more people than it helped downsize.)
But, I have to admit, the old systems weren't very flashy or flexible. We built them as fast as we could to get the savings, in order to build more systems, advance the art-and, of cou
rse, get promotions and raises.
Meat-Ax Technology
True, we didn't need to know much about the business in order to save money by mechanizing processes. Nor did we need to be very creative or worry about competition. In the old days, we used meat-ax technology. Brain-surgery technology is now available on the desktop. It can even be used by businesspeople-not disciplined programmers supervised by cautious technical managers.
Therefore, there's a rebellion against legacy systems because they don't always match the business-and because it's difficult and time-consuming to keep them in tune with the real world.
Some people even say businesses are complacent because of their legacy systems. This is a bad rap. Companies that bore the maintenance expense on legacy systems have shown us that old tricks can be taught to the new dogs.
And yet there are new, wonderfully user-oriented tools available to build systems with flexibility-and a little pizzazz, too. I wonder what kind of systems
will be designed using these tools. Will users (or even more creative programmers) be able to build business systems that have the flexibility of my PC package? I have the capability to link to other processes, change everything from graphics to hot spots with a click of the mouse, and update corporate data from my home. Will we tap this flexibility-and maybe lose stability-or will the new systems still suffer from the same problems as legacy systems?
I think I know the answer--but as I was reminded by my colleagues on a recent birthday, I'm a legacy system.
Dick Bellaver is associate director of the Center for Information and Communications Science at Ball State University in Indiana. He previously spent 27 years in the 'Olde' Bell System. He can be reached at
rbellave@wp.bsu.edu
.
Back to Columnists
Send Us Your Feedback
Top of the Page
ack when we did real programming, something positive could always be learned anytime we made a mistake. But that isn't necessarily the case now.
