IBM 610 workstation computer 3371

Philip Nasadowski

I've been on both sides of the fence--being a customer of a professional contractor and being the professional contractor.

Often times getting the customer to separate out what they want from how it will be done is difficult. Generally, it's up to the customer to best know the what, but the professional knows the best how.

However, professionals are not always perfect either. Sometimes a well experienced customer will find mistakes. Sometimes the contractor has idiotic management insisting in a particular bad approach.

Different contractors have different approaches, and some are indeed better than others.

The clbuttic example is the engineering approach is the differences between BART and PATCO as developed by their respective engineers. PATCO was more "low tech" and worked. BART was more high tech and didn't work. Of course, which was better in the long run is debatable. BART proponents have claimed that a PATCO style system would simply not have been attractive enough in the BART environment and I think there is some merit to that argument. In other words, PATCO could get away with using an existing old slow speed crossing and subway for part of its route while BART need all new tunnels. PATCO did save an awful lot of money, though.

A small township with some inventory parts isn't exactly what I had in mind. I was thinking more of a large programming shop where several hundred people already were well familiar with a language and platform. It may be better for some applications to continue with that language and platform, even if "obsolete" rather than deal with the cost of training and a learning curve for a new language.

In 1959 IBM introduced the 1401 computer and a programming language for it called Autocoder. When IBM introduced the System-360, it provided a hardware "emulation" feature so that 1401 users could run their Autocoder programs on the S-360 efficiently and without change until they got around to conversion. (Software simulators were too slow). Well, people kept on running their Autocoder well into the 1990s! (I think Y2k conversion finally end off the last stuff). Sure it was using something made obsolete 30 years ago, but it worked and saved time and there was nothing wrong with that.

Likewise, until the mid 1980s some people were still using clunky 40 year old IBM tabulator machines because it was still cheaper to use those machines than program the applications on the computer.

"Obsolete" is a relative and subjective term. The DC-3 airplane became "obsolete" 60 years ago but remained very popular and beloved because it did it's particular job very well. To this day they are still in use. IIRC, the Boeing 737 is a fairly old design but Boeing still makes them and it's very popular; Southwest Air makes good use of them.

I've seen many brand new technologies fail because the developers and users simply didn't have the real world experience. What works in a techno geek lab is a far, far cry from the real world of real people. Evolutionary improvements tend to work better than revolutionary improvements.

As an example, IBM developed System-360 architecture in 1964 and to this day 40 years later it is still going strong. Many of us wish the x86 architecture used in PCs had the some storage key protection S-360 had all along. S-360 has been significantly improved but the basic principles are unchanged. IBM attempted a replacement architecture "Future System" that was a big disaster and never made it out of the door.

In the application end of things, programmers have extensive experience with CICS (the on line transaction handler) and can build very robust powerful handlers compared to more "modern" technologies. This is not to say CICS is the only way to go--of course it's not--but rather to say just because it's old doesn't mean to junk it.