The Times they Are A Changin’

I was in a meeting with a customer very recently when the customer made a comment about 20ms being “forever” in relation to a problem he had been experiencing. It made me think back to when I started in programming and how long it took to write and compile a program back when I worked on a mainframe in the 1970s and 1980s.

This may seem as though it is from a totally different era, but his comment was true back in the mid-1980s.

I worked for the British Government in the Home Office. This government department dealt with everything that was not big enough to be a government department. At the time, covered large entities such as the Prison Service and Immigration down to small things such as permission for exhumations of bodies.

The developers were located in central London and the mainframes were located about 25 miles away. Communication between government buildings was achieved by a group of people called messengers who would wander the corridors looking for manila envelopes which they would gather up, and if it was an internal message, the messengers would deliver the envelopes by a van to the required government building. If the envelope was going to a non-government location, the envelopes would be collected by the Post Office.

This is how we created programs: each line of code was an individual punch card, some of my programs were over 5,000 lines long:

  1. Write out the program by hand using a pencil
  2. Put the program in a manila envelope on a van that was then delivered overnight to the building that housed the mainframe and the punch pool to create the punch cards (The punch pool was a group of women who were paid by the keystroke. If you’re wondering why women, no man was ever quick enough to pass the speed test.)
  3. The punch cards then went onto the van and arrived back at my desk the next day
  4. I’d check the card decks for spelling mistakes
  5. By hand, I created any corrections that needed to be made
  6. I’d send card deck on the van to the mainframe to be compiled
  7. I’d wait to get printouts back with any compile errors
  8. I’d again, by hand, create required corrected cards
  9. The card deck traveled again on the van to to mainframe to compile
  10. I’d wait and get printouts back with any compile errors
  11. Assuming the program compiled with no errors, I eventually sent deck to the ops group to run the program on the mainframe.

This is an example of a typical punch card.

The output from these programs were either a roll of paper tape which could be read by another system or sometimes a printout of results. In the later years, the system had terminals attached for the end users but it was not until 1986 that one of the revolutionary new IBM PCs arrived in our office and the days of the punch card being used to create programs started to be numbered.

Compiling and running a program was a minimum of 48 hours between submitting the longhand form of the program and getting the results from the program back, so the idea that 20ms is “forever” seems quite amusing to me these days, but it will be interesting to see what changes will take place in the industry in the next 40 years and how long customers and developers will be prepared to wait for results and the form that input will be created from.

Kevin Drury 1 Posts

Senior QA Manager Started in computing in the 70s (just 19th November 1979) for the Home Office and spent 9 years working on COBOL and ALGOL before moving to developing using Pick and System Builder in 1988. He left the Home Office and joined Ardent Software in 1998. Spent 3 years in support, 16 years in development and is now the manager of QA for MV and has been through the different acquisitions to now be part of Rocket Software.


Leave a Comment

Your email address will not be published.