• About
  • Jerry’s Story

swalchemist

swalchemist

Monthly Archives: August 2016

Jerry’s Story: Jerry, the Real Programmer

24 Wednesday Aug 2016

Posted by Danny R. Faught in Jerry's story

≈ 1 Comment

This is the third installment of Jerry’s Story. See the home page for Jerry’s Story for links to other installments.

Jerry Weinberg had worked as a shoe salesman, dishwasher, and camp counselor, among many other jobs. But he was finally getting to work with the “giant brains” that he had hoped to get his hands on. He asked to start two weeks early because, he says, “I had a wife and 1.66 kids by then, so I needed the two weeks’ pay.” Still living in Berkeley, he commuted across the bay to San Francisco on the F-train.

The first machine he used on the job was the two-ton IBM Type 607 Electronic Calculating Punch, which IBM also referred to as an “electronic calculator.” The term “computer” was in use at this point in the 1950s, but it doesn’t seem to have yet become the most common term for these machines. The job ad he had responded to referred to “electronic data processing machines.” It didn’t matter to Jerry what they were called—he was fascinated by these machines.

He hadn’t known that unit record equipment like the 607 had been in use since the late 19th century. Unlike the era of the IBM PC, which made IBM a household word in the 1980’s, IBM wasn’t marketing these data processing machines to consumers, so their existence wasn’t common knowledge.

Jerry was IBM’s first applied science representative in San Francisco. His first assignment was to teach a programming course to the three other applied science representatives who were starting two weeks later. He would soon be providing technical sales support to help salesmen sell leases for data processing machines and other IBM products. IBM would also send him to new customers at no additional charge to teach them how to program the computers, which usually also involved writing their first program for them.

8791024600_b4c3b971c0_k

Plugboard, system type unknown. Photo by Simon Claessen.

There was no training available for learning how to program, but there was a set of manuals. Jerry dug in to the manuals for the 607 and mastered the machine in a week. This was a wired program machine, programmed by plugging wires into a plugboard. [Note from the editor: The 607 was a data processing machine, not a stored program computer.] He still easily remembers the technical details—20 wired program steps (this was expanded from the base model with 10 steps) and one signed ten-digit number of data storage. This was a big advance over the desk calculators he had used before. He also got familiar with other machines, like the keypunch, verifier, reproducing punch, collator, printer, and sorter. Some of these could also be programmed in limited ways, such as formatting and adding totals with a wired program on the printer, or defining the formatting for the cards on the keypunch using a special program card.

Jerry earned a reputation as a whiz kid by making the 607 do tricks. He won a dollar bet by turning on all the lights on the 607 control panel, which no one else in the office had figured out how to do. Jerry sums up his feelings about his new job: “I was being paid $450 a month for playing with the world’s greatest toy, a job I would gladly have paid $450 a month to do—though I wisely didn’t tell IBM that.”

Jerry moved on to learning how to program the IBM 650 Magnetic Drum Data-Processing Machine before the San Francisco office had one available. This was the world’s first mass-produced computer, and the first stored program machine that he encountered. The machine arrived a short time later.

There is a legendary story about Mel Kaye, the “real programmer.” Mel wrote hand-optimized programs for the Librascope/Royal McBee LGP-30 and RPC-4000 computers, which had storage on a rotating drum like the IBM 650. Mel implemented tricks like placing instructions on the drum so that after an instruction executes, the next instruction would have rotated to the read head at the moment it was needed. This eliminated the need to wait for the drum to rotate to the instruction before reading it. There was an optimizing assembler, but Mel’s hand-coded machine language programs always ran faster than the equivalent automatically optimized assembly program.

In order to optimize the amount of space a program occupied on the drum, when he needed a number in a calculation, Mel would try to find an instruction code in the program that happened to have that number, so he could just refer to the same memory location rather than adding another storage location to hold the data. The ultimate optimization described in Mel’s story involves using features of the machine that aren’t documented at all.

To learn about his competition, Jerry later wrote a few programs for the LGP-30, though he didn’t have a chance to run them. Recalling the IBM 650, which was similar in some ways to the LGP-30, Jerry says that the kinds of manual optimization described in Mel’s story were very common, and necessary if you wanted to have an efficient program. The optimizer might even cause a correctly written program to crash the computer. There was an assembler called “SOAP” (Symbolic Optimizing Assembly Program) that tried to place the instructions in an optimal location on the drum. Jerry says, “SOAP was okay for many programs, but for critical apps, we optimized by hand.”

Ed Nather, the person who wrote Mel’s story, was the programmer who tried to understand Mel’s code. It was a convoluted mess, almost impossible to decipher. Most of the Mel’s optimizations made the code harder to change, but even so, Ed wrote of his awe of Mel’s programming prowess. Programmers at that time did not consider maintainability an important attribute for their programs.

One of the optimizations that Jerry applied was on the IBM 704. There were many possible values for machine instructions that were not documented. Programmers were expected to only use the codes (often called “opcodes”) that were documented and supported. But of course, some of the programmers were curious, so they experimented with the undocumented opcodes, and found that a few actually were useful. One of them was a single instruction that would clear a memory word—the supported way to do this required two instructions. They coined a new instruction, Store Zero (STZ).

Someone added the STZ opcode to the assembler that was distributed by the SHARE user group, so all 704 programmers could use it and reduce their program size. Later when IBM produced the 709 and claimed it was compatible with the 704, Jerry and other programmers found that the STZ instruction no longer worked. They pressured IBM to add the STZ instruction so that they wouldn’t have to modify every program that used it. IBM complied, but if they hadn’t, the programmers would have had a big job in modifying their programs to work on the 709.


Less than a month after Jerry started the job, IBM chairman Thomas J. Watson Sr. died. This inspired a lot of talk in the office that informed Jerry about company history. It can be interesting to trace the machines of IBM’s roots to what Jerry experienced there starting in 1956. IBM started life as the Computing-Tabulating-Recording Company, which itself was formed from the merger of four companies in 1911:

  • Computing Scale Company of America—manufactured “computing scales,” scales similar in function to modern butcher scales, which weighed a product and calculated its price at the same time. They also made meat slicers (you can watch a video of a hand-cranked IBM meat slicer). Jerry only encountered these scales and slicers via the stories people shared about the history of the company.
  • International Time Recording Company and Bundy Manufacturing Company—both interrelated companies manufactured time clocks, tracing their roots to the world’s first time card recording company. Jerry never got involved in selling time clocks, but he does remember being required to punch a time card, simply because it was “part of our business.” When IBM sold the time recorder business to the Simplex Time Recorder Company in 1958, Jerry hopefully asked if he could stop punching a time card that didn’t really help anyone. The answer was “no,” but in fact the practice of punching in and out did fade away in his office. Bundy also got involved in producing adding machines, but these didn’t seem to make their way into IBM’s DNA.
  • The Tabulating Machine Company—Founded by Herman Hollerith, who built a tabulator that successfully processed the data for the 1890 census in the U.S. This machine was the first in a long line of unit record equipment, which includes the IBM 607 that Jerry started with, and evolved into modern computers.

One more later acquisition is worth mentioning here–

  • Electromatic Typewriters, Inc.—IBM entered the typewriter business with this acquisition in 1933. Jerry helped sell “a slew of typewriters,” which established his reputation in the office. He remembers that a typewriter salesman was making a pitch to a biologist who was doing genetic research. The biologist wanted to buy several IBM Selectric typewriters, but he needed to be able to make the standard symbols representing males and females. The salesman couldn’t find a typeball in his catalog that had those symbols, so he sought out an applied science representative to help. Jerry remembered that these symbols were also the astronomy symbols for Mars and Venus, and with this help, the salesman sold five typewriters. After that, salesmen started to bring a variety of problems for Jerry to help solve.

The next installment in this series is Jerry’s Story: The Roles of Jerry Weinberg.

What, us a good example?

18 Thursday Aug 2016

Posted by Danny R. Faught in testing

≈ 1 Comment

I was pleased to hear Alan and Brent respond to my post “The black box tester role may be fading away” in AB Testing – Episode 43 (starting at 9:52). Their primary response was to my claim:

“The project structures they describe seem to be on the leading edge of the future of the software testing role. In my limited view of the software industry, I don’t see many companies that are anywhere near Microsoft in their evolution.”

They don’t think they’re really on the leading edge. I suspected that they would protest, because it’s human nature – everything is relative. If the organization I’m working with has a long way to go to achieve something that theirs is already doing, and I feel that theirs is a good enough exemplar, I don’t need to seek out something that’s even better. But from their point of view, they want to improve with the help of others who have gone even further, so their sights are set on others who have gone beyond. I’ve seen many software organizations recently that are so far behind in their evolution that it’s easy for me to point to Microsoft (which granted, I’ve also found many reasons to malign) and say that they’re far ahead of the pack.

These organizations that are behind the curve are generally surviving, and their companies are usually still making a profit. I saw this many times in my consulting. They are more or less successful and often don’t feel a strong need to make significant changes. This is where the traditional approach to software testing will hang on for a long time and keep the black-box testing role alive. At least for me, though, these are often not desirable places to work, and they may eventually find that it’s difficult to hire talented testers. Note that I’m more concerned about some of the antiquated traditional practices like scripted manual testing than I am with the black-box tester role itself, for now.

By the way, I’m amused that Alan introduced me as “our good friend,” but then didn’t seem to know whether that was okay to say. I’ve found that calling someone a friend often makes it so. I owe you guys a hug.

 

The black box tester role may be fading away

16 Tuesday Aug 2016

Posted by Danny R. Faught in testing

≈ 3 Comments

Is the traditional software tester role fading away? A recent blog post from Cem Kaner helped to reinforce this idea for me. You’ll find his comments inside this long post, in the “2. Oracles are heuristic” section, under the heading “A supplementary video”: Updating to BBST 4.0: What Should Change. Incidentally, the topic of the whole post is updating a course on software testing, which I think I attended a very early variation of around the turn of the millennium.

Cem’s parenthetical notes on tester careers are interesting. He suggests that traditional black-box testing (whether exploratory or scripted) will give way to piecework, where a tester will be paid by the number of completed tests. I’ve seen this model already underway in outsourcing companies like Rainforest QA and its competitors, where the manually executed test step is the basic unit that you’re paying for. It’s much easier to see this happening for scripted tests than for exploratory tests, and I argued against using this kind of service when an executive asked me to consider using it, because I see little value in scripted manual tests.

You can imagine that this kind of piece work will not pay testers very well. Cem noted that he already sees a significant pay differential between black box testers who don’t do any programming and those who have jobs that require some kind of programming. He suggests a few skills like programming that testers could add to become more marketable. I have a few items of diversification I can point to, including programming and automation skills, though I don’t often focus on automation. I’m familiar with testing web apps and mobile apps (and even mobile web apps :). My experience with embedded systems often gets the attention of recruiters.

I’ve added a few items to my resume this year that I’m happy about. I took a training course and became a Certified Scrum Master so I could understand the leadership aspect of agile processes better. Perhaps the most promising, given the current job market for security, is the Certified Ethical Hacker course I took and passed the exam for. I know that passing a certification exam doesn’t really prove anything, but these particular certifications do seems to carry some weight that might help my career. Both are subject areas I already have experience in, and I was happy to round out my knowledge in the classes.

I’ve been following Microsoft employees Alan Page and Brent Jensen on their AB Testing podcast. They both have had fairly traditional testing roles, but now are in roles that seem to be much more future-proof. Brent is now a data scientist, specifically, Principal Data Scientist Manager. Alan, Principal Software Engineer, describes himself as a helper, doing the odd (but challenging) tasks that don’t easily fit the developer roles on his team, which is something that appeals to me. Both are still involved in the testing process. The project structures they describe seem to be on the leading edge of the future of the software testing role.

In my limited view of the software industry, I don’t see many companies that are anywhere near Microsoft in their evolution. If the traditional black-box tester role is fading, I think it’s going to happen very slowly. I think it will require a very broad view of the industry to track a slow evolution like this, and I’m curious if you’ve heard from anyone who is in a good position to see it.

Recent Posts

  • Seeking the Inner Ring – Revisited
  • Use Your Unit Tests, or Else
  • Open-Minded Networking
  • Design Evolutions Doomed to Never Finish
  • Adventures in Personal Library Management

Recent Comments

Danny R. Faught's avatarDanny R. Faught on Seeking the Inner Ring –…
coutré's avatarcoutré on Seeking the Inner Ring –…
Danny R. Faught's avatarDanny R. Faught on Use Your Unit Tests, or E…
coutré's avatarcoutré on Use Your Unit Tests, or E…
Five for Friday… on Four Years after the 343

Archives

  • October 2025
  • September 2025
  • March 2025
  • August 2024
  • July 2024
  • June 2024
  • May 2024
  • March 2024
  • February 2024
  • February 2022
  • September 2021
  • August 2020
  • July 2020
  • February 2019
  • December 2018
  • October 2018
  • August 2018
  • June 2018
  • March 2018
  • February 2018
  • October 2017
  • September 2017
  • May 2017
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • September 2013
  • August 2013
  • November 2006
  • April 2003

Categories

  • archive
  • career
  • Jerry's story
  • life
  • security
  • software-development
  • technology
  • testing
  • travel

Meta

  • Create account
  • Log in
  • Entries feed
  • Comments feed
  • WordPress.com

Blog at WordPress.com.

  • Subscribe Subscribed
    • swalchemist
    • Join 26 other subscribers
    • Already have a WordPress.com account? Log in now.
    • swalchemist
    • Subscribe Subscribed
    • Sign up
    • Log in
    • Report this content
    • View site in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...