Friday, January 29, 2016

Evolution of reuse/subroutines/functions/services Part 1

This post is a potted history of the ways we have seen reuse work in software over time. It is a somewhat personal history, starting with my first foray into software in 1967. I didn't invent any of this - but was a beneficiary.

The first exposure I had was when I did a summer internship at Gloucester Polytechnic in 1967. We were allowed to get our hands on a real live computer. Paper tape was the only mechanism for getting programs and data into the beast. The programming language was called City and Guilds Mnemonic code. It was an early teaching environment running on an ICT 1900 series computer. We were given the task of using Heron's formula for calculating the area of a triangle. This involves taking the square root of a number at the last step of the calculation.
The really important part of the exercise was writing the square root function in this very low level language. We were instructed to use a Newton-Raphson iteration method. This was quite tedious! After about 2 weeks I finally had this beast working. It was coded on paper tape using a machine like this.

The paper tape device had a useful feature - you could make an exact duplicate of an existing tape. That was how we corrected bugs in the program. Copy the working bit of the code. Stop the copy. Type in the new code. Advance the original to the point where you wanted to continue from and continue the copy. No wonder the square root took 2 weeks.
At which point, the instructor said, "You can't be the first people ever to create a square root function, so why do it again and again? Especially as there may be errors in your version."
He the pointed to a row of coat hooks. Above each coat hook was a DYMO embossed tape label naming a function. Hanging on each hook was a loop of laminated paper tape containing the code for the function.
The procedure was:

  1. Identify the function you need
  2. Locate the coat hook
  3. Take the tape loop
  4. Place the loop into the input side of the tape copy machine
  5. Position the tape on the output side where you need the function
  6. Copy the code from the input to the outside
  7. Remove the laminated tape from the input side
  8. Inspect for nicks/errors
  9. If the original is damaged or showing signs of wear, give it to the computer lab tech to have a new copy made
  10. Either the original or new copy of the function is replaced on the hook.
These physical images have stayed with me since then. And they help me as I think through the pros and cons of different coding approaches.
  1. First locate the subroutine or function (if one exists). The "FIND" step
  2. Make the subroutine/function available to the program. The "BIND" step
  3. Execute the program containing the function/subroutine. The "EXECUTE" step
Of course FIND/BIND/EXECUTE model doesn't tell you how to create good subroutines/functions. But it does provide a good thinking model for what has to happen when you want to use a previously developed routine.
  1. How do I know where to look? Where are the coat hooks?
  2. What searching ability do I have? Can I read the DYMO label?
  3. Do I inline the code (copy/paste in modern parlance)? or do I invoke it (lots of ways)? Inline was all I had
  4. Who has the ability to create new copies? Who are the lab technicians?
In other articles in this series I will look at mechanisms from link libraries, component libraries, shared functions, open source, services, micro-services and associated mechanisms for the FIND/BIND/EXECUTE model


  1. Ah, the advantages of paper tape! Whenever I tried something like that with Hollerith cards the card punch machine jammed.

  2. A good visceral lesson and a fun trip down memory lane.