1980: Small Functions
This is the 3rd in a short series of articles around my 4-decade+ career in software development — for your amusement, edification, and to capture a bit of computing history. They also bring back some memories for me, fond and otherwise.
I wanted to be a chemist. At Eleanor Roosevelt Senior High School (ERSH) in Greenbelt, Maryland, I ended up taking three chemistry classes, confident in my career choice. But I started taking computer classes in my junior year (1980–81) and ended up getting hooked.
The school owned an HP/3000 minicomputer that they used for school operations. We students also used it for classroom purposes. Cool! Some enterprising students (like Frank McConnell, a senior ahead of me) mastered the machine, learning far more about it than anyone working at the school.
Back then, you didn’t write your code (FORTRAN and BASIC, mostly) in a full-screen editor — those became prevalent a handful of years later. Instead, you used what’s known as a line editor; the better one on the HP/3000 was a piece of software known as EDIT/3000. (A later, improved version was known as TDP/3000.) You viewed pieces of your code by executing a command within EDIT:
> L20–30That command would (L)ist the 20th through 30th lines in my program source.
The Hewlett-Packard HP2640 terminal, a common model for the HP/3000, typically provided 24 lines on a monitor that maxed out at 25 lines by 80 characters wide each. The 25th line was used to display the available function keys. Since the EDIT command line took up one line itself, the most lines of code I could see on the screen at one time was 23.
You could buy extra memory for HP2640 terminals to allow for scrolling back across multiple screens. (By the mid 1980s, I was thrilled to have enough extra screen memory to support 10 screens worth of scrolling back.)
The ERSH computer terminals were donated by someone, not purchased. And that donator figured they’d remove memory, since it was no doubt fairly expensive at the time. As a result of the memory loss, we had terminals that displayed only 17 lines, not 24. Subtracting one more line — for the command line itself — we saw at most 16 lines of code on-screen at a time.
I got good at doing the “advanced math” needed to see the most lines possible. To see exactly the 16 lines starting at line 12:
> L12–27(I recall that there was also a way to give it a delta.)
If I couldn’t see all of the lines in the function I was working on, I found it a lot harder to reason about the code. I initially did a lot of back and forth. The following command to list lines might only show part of the function and not all of what I need:
> L12–27I’d then list the rest of the function, or at least the next 16 lines, using another command:
> L27–42Great, I can read the rest of the function. But, hmm, what was that preceding bit of code doing? I’d issue another command to “scroll back” to see it:
> L12–27…and see the detail I’d temporarily forgotten.
And so on, back and forth to list one sub-chunk of the overall function at a time.
The nuisance of scrolling drove me to create functions that were at most 16 lines long. In those days, most functions were longer. Most of mine now fit neatly on a single-ERSH-screen.
It turns out that crafting short functions drives toward one of the most important software design concepts — something that today might be referred to as the single-responsibility principle, composed method, or perhaps cohesion. (They’re all similar though there are nuanced differences). In turn, this concept is the foundation of a lot of other great ideas in software design.
In limiting my function length to deal with my abbreviated screen height, I was following the late, great Jerry Weinberg adage that he named the Bolden Rule: “If you can’t fix it, feature it.” Except at the time, I didn’t know that I was “featuring” smaller functions due to my inability to fix the problem. It just seemed easier to me to give in to the limitation and shorten my functions.
In turn, programming itself began to seem easier the more I coded that way, though it took me a while before I explicitly thought about it enough to understand why. In 2004 I wrote an article subtitled “Nine benefits of making your methods shorter;” I could probably add another dozen today.
When I learned about the Bolden Rule, I viewed it as a way to help me sell a flaw. But I love most how it helped me feature a core design concept underpinning a 40+ year career.
