In the Beginning was the Subroutine

In 1951 was published what is arguably the first book about programming. It was called “The Preparation of Programs For An Electronic Digital Computer”[1]. It was written by Maurice Wilkes (designer of the EDSAC), David Wheeler (of Burrows-Wheeler Transform fame), and Stanley Gil (EDSAC pioneer).

The second chapter of that book introduced the concept of subroutines to the world. It was a way to decompose a program in smaller parts in a way to make computers more general tools, capable of performing several kind of operations beyond arithmetic ones:

A digital computing machine can perform only the basic operations of arithmetic, such as addition, subtraction, multiplication, and division.

Another more interesting use of subroutines was that of decomposing a program in smaller parts. While we were still far away from the wonders of structured programming[2], we see that the authors understand the need of having a way to facilitate software construction.

They see that subroutines will also help with testing, and if necessary bug fixing. Also, having a library of ready made subroutines will speed up the process of creating software[3]. Who would have thought that code reuse would become so important in the future?

Then the next year David Wheeler wrote a paper about subroutines where he expanded his ideas on the topic. It was called “The use of Sub-Routines in Programmes”[4].

There he describes a subroutine as:

a self contained part of a programme, which is capable of being used in different programmes

He notes that it is not necessary to write programs in this way, by subdividing them into smaller parts, but by doing so we not only gain software reuse, but we make the software easier to understand and test. Programmers can focus on each part of the problem separately and then compose them to form the solution to the original problem. It’s interesting to see that since the dawn of our discipline people understood that there’s no need for software to be elegant, since the machine would be able to run it without problems anyway[5], but since programming is a human activity we need to create techniques that allow humans to work better with software, whether when we are building it, or when we are testing it.

Thus the subroutines can be more easily coded and tested in isolation from the rest of the programme.

They understood that being able to test subroutines separately would increase the confidence of the overall program, since it’s easier to prove the correctness of a program when we know the individual parts that compose it work without errors. Then they used master subroutines that would work as what we call today integration testing to make sure the whole program worked as expected.

Another interesting point Wheeler discusses is the fact that when we create a library of subroutines, by gaining generality we may lose performance, since we need to adapt the subroutine to the library standard. Still he thought that the hardest part of creating a library was documenting it so other people could use it. 65 years have gone by and we still face the same problem of having useful software documentation.

However, even after it has been coded and tested there still remains the considerable task of writing a description so that people not acquainted with the interior coding can nevertheless use it easily. This last task may be the most difficult.

The paper finishes laying out the goal for writing subroutines. Again, note that they are not necessary.

The above remarks may be summarized by saying sub-routines are very useful — although not absolutely necessary — and that the prime objectives to be born in mind when constructing them are simplicity of use, correctness of codes and accuracy of description.

Writing clean code is not a requirement for a program to work, but it becomes a necessity when we want to have code that it’s easier to use, prove correct and most importantly make sure that solves the problem we wanted to solve in the first place.

All complexities should—if possible—be buried out of sight.

Notes:

1. The Preparation of Programs For An Electronic Digital Computer. https://archive.org/details/programsforelect00wilk

2. Structured Programming. http://dl.acm.org/citation.cfm?id=1243380

3. Keep in mind that as seen on the picture on top, subroutines were actually stored in a library!

4. The use of sub-routines in programmes. http://www.laputan.org/pub/papers/wheeler.pdf

5. See http://alvaro-videla.com/2014/09/a-programmers-role.html