Re: Market pressures for more reliable software

[Lao Xiao Hai <laoxhai@ix.netcom.com>]

"Shmuel (Seymour J.) Metz" wrote:

> Lao Xiao Hai wrote:"Perhaps.  But, for most organizations, emphasis on the word most,
> computing
>
> > resources within an organization was under the centralized managment of
> > one central authority.  Moreover, most of the computing was located in one
> > place.  It is true that some very large corporations had computers distributed
> > across their divisions, but that was a luxury not affordable by most of industry.
>
> You're missing the point the centralized equipment does not imply centralized use of
> the equipment.

I must be missing the point.    What was not centralized?   Programming was pretty
much centralized and under the control of a data processing manager.  Computers
were pretty much centralized, and there weren't that many that could drive remote
terminals really well.  Most of the data processing was in batch mode.

> > This centralization, during the 70's and through the mid-80's even extended to
> > collections of companies.   Ever hear of a service bureau.
>
> ROTF,LMAO! Heard of them? I've worked for them. I've never heard of a service bureau
> where the programming was centralized; the norm was that the customer did his own
> programming.

That is not how I remember it.  Most of the programs I recall were written by the
programmers
at the service bureau.  Some were packages purchased from elsewhere.   It was the rare
customer who had programming resources on which they could rely for their own software.
Usually, this task was contracted by the programmers within the service bureau.  Later,
there
were independent contractors who could do this for hire by the service bureau customer.

> > Networks were still a mystery for most people.
>
> Most people didn't work with computers. Dialup access was common in the late '60s.

Not that common.  And it was expensive.   We used it quite sparingly in most places.

> > Programmers were busy
> > grinding out programs in COBOL.
>
> I take it that you never had anything to do with scientific computing?

I have done both.   Certainly a lot of scientific computing was done using remote
computers.   However, I recall quite vividly those sites that had their own IBM 1130
and did their own Fortran programming.   I spent many late night hours writing Fortran II
and debugging on the 1130.

> > Compilers needed large memory spaces
> > and operating systems and these were hosted on million dollar plus machines,
>
> Yeah, like the 650, 1401, 1620 and 1130? Maybe they weren't glamorous, and they were
> too small to be of interest to service bureaus except for the odd 1401 used as c/t and
> t/p, but there were a lot of them.

The IBM 1401 was the workhorse of industry for a long time.   It was the first machine
I learned to program.   It was not cheap.   In the companies where I worked on that
computer, we usually had more than one, just to get the work done.  There were almost
no programmers from outside the company.   The other computers you named were
certainly small, but they were also under the control/guidance of the MIS manager
at many companies.   Oh, and you forgot one of my personal favorites, the CDC
160 series.   The IBM System 360 series came along in 1964 and, along with its
clones and cousins, did required lots of memory, lots of dollars, and lots of
programming talent.  Most of those machines were still centralized up through
the mid-1970's when the minicomputers became common.   Even those minicomputers
were pretty much centralized in the small businesses that leased them.

There was some decentralization.   But I don't recall it being as widespread as you do.
This is particularly true of data processing, which was almost always centralized in
those early days.   It was certainly not decentralized in the way it is today.    Even so,

I am noticing that some very large organizations are moving back to a more centralized
computing authority.    User developed applications  (UDA's) are getting out-of-hand
and instead of saving money, are costing money.     Worse, many of the amateur
programmers who create UDA's are failing to build in the kinds of error control and
security one would expect of more rigorously defined software.   This is creating
vulnerabilities that would not have been tolerated in the centralized era.

Richard Riehle