The title of this post was the subject of an email I sent to the great Jerry (Gerald) Weinberg before he had passed away in 2018.
If you’re not familiar with Jerry, here’s a snippet from his own blog. He was an important figure in our profession:
Early in my career, I was the architect for the Project Mercury’s space tracking network and designer of the world’s first multiprogrammed operating system.
I won the Warnier Prize, the Stevens Award, and the first Software Testing Professionals’ Luminary Award, all for my writing on software quality. I was also elected a charter member of the Computing Hall of Fame in San Diego and chosen for the University of Nebraska Hall of Fame
He went on to write many useful books, which we still use today to learn a great deal from. One that immediately comes to mind that a lot of colleagues have recommended is The Secrets of Consulting. Much wisdom has been gained by reading this book I’ve been told. I plan on reading it as well.
Started in 1958, Project Mercury was the United States’ first manned spacecraft program. The program included a number of unmanned test flights, some including primates, prior to flying human astronauts.
A total of six manned missions were flown. Two suborbital missions were followed by four orbital missions. Suborbital missions were launched using Redstone rockets, while orbital flights were made using Atlas launchers.
Punch Card TDD
It wasn’t the modern form of TDD as we know it now from Kent Beck which utilizes smart/fast IDEs, fast Compilers, etc. Kent has always been careful to state, that he “reinvented” TDD, not “invented”. Now you know why.
The Mercury team was practicing the same workflow essentially by use of punch cards to think about what the code should be before it was actually processed (before punched cards were processed) and verified.
Side Note: There’s a lot of history just in general over the past 50 years when it comes to TDD, a lot of it stemming from Illinois where I currently live, and Chicago, IL was where Jerry was born.
An Email to Jerry
I reached out to Jerry in 2018 via an email inquiring about some details about how they test drove code back then. His blog post How We Used to Do Unit Testing was pretty vague so I wanted to find out more if I could.
I was surprised that not only did he reply but in much more detail than I had anticipated. In the course of over several months starting from Jan 2018 to June 2018, replies slowly trickled in.
Without ever formally meeting him his passion about testing, good code practices, and the dedication to the Craft of Software Development was clear when he took the time even during poor health to write detailed and thought out replies to my questions.
Thank you Jerry for your invaluable replies!
I was reading your blog post here: How We Used to Do Unit Testing
I had a quick question; what did you mean here by this?: we sketched out a set of test cases before putting pencil to coding pad
I couldn’t quite read between the lines there, especially on the “before putting pencil to coding pad” portion.
I have always been into the history of TDD, XP, Agile. And so I’m working on an upcoming ReactJS TDD course. My first lesson is going to be a Deep Dive into TDD/XP history with my students. So I’m including you in it :), in the part about punch card TDD.
I would be so grateful if you could kinda clear up that sentence for me a bit as I try to include some of this information in my talk with your permission and get this as accurate as I can.
I’m not sure I understand what you don’t understand. Maybe you’re too young to know about punch cards and old computer abilities.
In the earliest days, the machines (like the IBM 640 and the IBM 704) had only two forms of input. One was entering binary code through the console, with a toggle switch for each bit of a 36-bit instruction, one instruction at a time. (that was only the 704. the 650 didn’t even have that)
The other method was punch cards. Each card could hold 80 digits, or with “double punching” up to 80 characters. On the 704, the cards could also hold binary instructions, but only rarely would you program directly into binary cards.
We didn’t have terminals, or monitors. If you wanted output, you either had the computer punch cards which you then printed off line, or if your machine had a printer (not all did), you printed directly from the machine.
So, you entered your program on punch cards, but you generally didn’t sit down at a keypunch and write your program (though you might make corrections and small additions that way). First we designed the program, typically using flow charts to diagram the designs. Then we coded from the design.
Typically, you wrote the program on paper, often on a special form called a coding pad (but not necessarily, because any piece of paper could do). Most of us used pencils so we could erase, and we often wrote on every other line so as to leave room for corrections.
The coding sheets were then transcribed into punch cards, sometimes by the author (we weren’t yet called “programmers”) or sometimes by a professional keypunch operator. The punch cards were then often passed through a key verifier (essentially a double keying to detect errors), but that wasn’t always done.
Once punched, these source cards carrying the program were then read into the computer, assembled or compiled, and object code cards were then punched out. The object cards could then be read in and the program executed.
I suppose this process sounds cumbersome, and it certainly was, but it was what we had. Perhaps because it was so cumbersome, or perhaps because the machines were so costly, we tried to avoid many cycles of coding-testing-correcting. We wrote out tests up front to the extent we could, had them punched into data cards, and when the code was ready, used them to run our tests.
Typically, our goal was to have no more than one cycle of corrections. This was made even more important when we were in Los Angeles, running our tests on a 704 in New York, with the punch cards being sent by (non-jet) air freight. At least 95% of the time, our programs ran the first time without error, in large part because of our pair programming practices and code and test reviews.
Does that help?
I’m really glad you’re still with us and hope you’re doing well.
I was reflecting back on our conversation below. And wanted to find out more about how it was back in those days when you gathered requirements from the business.
I know “Agile” or “Agility” was not a term back then but I’d assume you worked closely with the business in an agile-like fashion back then?
I was curious how that went back then, a typical week with the business in terms of getting requirements, reviewing them, and showing them once a feature was done.
Sorry for the delay, but I’ve been thinking a lot about your request.
Here’s what I’ve come up with.
I don’t think there was a “typical” week. Every week brought new surprises, back when pretty much everything was new.
One problem we had to grind through many times was the conversion to computers off manual or paper data collections.
How do you get 6,000,000 hand-written file cards into the computer?
Answer: tediously, with enormous numbers of errors, both on the cards and in the transcriptions. These 3x5 cards were the way the company kept their credit card records, written by hand. We had the help of several dozen young women to transcribe them into punch cards, from which we made mag tapes. And tried to check them (ugh).
Another problem (one that persists today) was depending on a single source of customer information. We didn’t know better, so we often built programs that did what our source wanted done, but did not satisfy the other people in the source’s organization.
Those are the memories that stand out for me about those days long ago.
One more thing. There was no “computer science” back then, so all our new hires were people with zero computing experience. You might think that was bad, but it was good. We had to train them from scratch, so they accepted the way we did things and had no foolish ideas they picked up in some college course. That was very, very good, though I don’t think we appreciated it at the time, since we had not seen some of the alternatives we have today.