What I Learned at Macy's about Enterprise IT

In my first IT job out of college over a half-century ago, there are lessons learned that still apply today. The technologies were old, but the lessons are timeless.

As incredible as the changes have been in information technology over the decades, what is also fascinating is the ways in which things have not changed. As I am approaching the half-century mark in my career, I thought it would be helpful to look back to understand the lessons learned that still apply today.

As you can imagine, this will be a much more personal post than usual. And be sure to check out the end notes, which include interesting but tangential details about work life during that time.

My career began at R.H. Macy in 1974, at its headquarters and flagship store at Herald Square in Manhattan, made famous in part by the film Miracle on 34th Street. Just as in the movie, the store was directly across the street from Macy’s greatest rival at the time, Gimbels. And, even in 1974, much of the building looked the same as it did in the 1947 movie.

Hired with No Experience

I did have some programming courses at the University of Pennsylvania, which I took after I realized that my geology major probably meant a career in the oil patch or in mining regions of the world—not places where I particularly cared to live. So, I thought, how about computer programming? As an undergraduate, I had one course in programming at Penn’s Moore School, home of the ENIAC, one of the first digital computers. In that course, I learned some Fortran and ALGOL, both now largely forgotten. The next year, I took a graduate course in IBM assembly language. I also did some Fortran programming for a few months for a professor in environmental science at nearby Drexel University.

This was the extent of my programming experience by the time my newlywed wife, Dorothy, and I moved to New York City. She took a job as a medical transcriptionist at New York University Hospital [1], and I started searching the classified ads in the New York Times.

Macy’s was running an ad for computer programmers. A college degree was a prerequisite, but no programming experience was required. As part of the hiring process, Macy’s administered a test for programming aptitude—mostly for ability to understand symbolic logic. I aced it, and I was hired into a group of about 25 applications and systems programmers.

Interestingly, Macy’s Data Processing (DP) department (as it was known before MIS or IT became the common term) only hired trainees. Even the department head, Joel Thayer, had started as a trainee. (In addition to his job responsibilities, Mr. Thayer was also the head of the roller-skating clown act in Macy’s annual Thanksgiving Day Parade. I regret that I was invited to join but never did.)

Go Talk to the Users

COBOL and IBM assembly language were the two programming languages in use then at Macy’s. I’d had a little assembler language training but no COBOL. So, Mr. Thayer sat me down at my desk [2] and gave me two COBOL training manuals to study. After a day and a half, I got bored and told him I was ready for an assignment.

So, he brought me into his office [3] and explained that we were a few months from the holiday season and that he had a quick project for me: Take Macy’s entire credit card account file and print “Holiday Money” coupons for eligible customers. These could be used by account holders like cash in the store, except that any purchases made would simply go on their credit card accounts. The thought was, if you give people something that feels like cash, they might spend more, or at least choose to shop at Macy’s rather than at a competitor’s store.

It was a pretty straightforward specification [4], and I thought I could write the code [5] based on Mr. Thayer’s verbal instructions. But first he told me, “Now, put on your sports jacket, and go down and talk to Richard Miles, the VP in the credit department, and be sure this is right.”

Less than two days on the job as a trainee, and I was going out (by myself!) to talk to a senior executive about his requirements. I’m pretty sure that Mr. Thayer knew it wasn’t necessary to have me do that interview, and, as expected, the meeting was uneventful. But Mr. Thayer was teaching me my first lesson.

Lesson Learned: Here’s the first way things have not changed. As IT professionals, our job is not just about technology. It is about understanding the business, and you can only learn business requirements by getting close to the users. Keeping with this principle, every new programmer at Macy’s started with the role of programmer/analyst, not just programmer. Understanding user requirements was part of the job from your first day.

Programming without a Computer

I can’t find evidence of this, but the old timers told me that Macy’s was only the second or third commercial organization to deploy a computer, one built by National Cash Register (NCR) in the early 1950s. Of course, in those days, virtually no one had experience in computer programming, so Macy’s trained its own programmers from the ranks of a department known as “Systems and Procedures.” (More about that department in a moment.)

At the time I was hired, there were still two or three of those first programmers working at Macy’s, now as DP managers. The most senior one, Abe Horstein, was the original programmer who wrote the code for the accounts receivable system, which managed all of Macy’s credit card operations.

Although Macy’s rewrote this system in the 1960s in COBOL for the IBM mainframe, Abe was still the go-to guy when we had questions on the program logic. To refresh his memory on particularly complex sections of the code, he would reach down to the bottom drawer of his desk and pull out a three-ring binder with old dog-eared hand-drawn flow charts, which he called bubble charts, similar to what I’ve drawn below [6].

During one such session with Abe, he told me a funny story. Macy’s contracted with NCR for that first computer, probably a year or so in advance of its being built. In the meantime, Macy’s wanted to get started on its top priority—computerizing that A/R system. Abe was tapped for the job. He learned to code and began a months-long effort to design and program the new system. The plan was to have Abe fly to California (I believe) to test his program prior to the new computer being shipped to New York.

Finally, the big day came. The computer was built, and Abe was ready to fly out west. But first, fearing the possibility of a plane crash, Macy’s top management insisted on photographing the hundreds of pages of handwritten computer code—but not as a backup. They actually kept the originals and sent Abe with the photocopies!

Ultimately, Abe got the program running and the new computer was shipped to New York, where it supported Macy’s A/R system [7]. By the time I left Macy’s two and a half years later, I was responsible for the nightly processing and maintenance of that system, now rewritten for the IBM 360 [8].

Lesson Learned: Some programmers today think that well-written code is its own documentation. I disagree. Well-written code can explain what the program does, but what is often missing is the “why.” Although program flow charts are usually not needed, there is still the need for documentation at a higher level, especially concerning the business logic. Throughout my career as a developer I always made an effort to document things I thought my successors would want to know.

Does Macy’s Tell Gimbels?

My first programming assignment was successful. After I had finished, Mr. Thayer told me a funny story. As noted earlier, Gimbels department store was still across the street from Macy’s, and the two were rivals. In fact, “Does Macy’s tell Gimbels?” was, at the time, a common saying indicating that competitors do not share business secrets with one another.

Despite this intense rivalry as retailers, Mr. Thayer and his peer at Gimbels had somehow managed to enter into a friendly competition whereby each of them would attempt to find vulnerabilities in the store processes of the other.

To facilitate the competition, Mr. Thayer had applied for and had received a Gimbels credit card. As a result, Mr. Thayer had received, in the mail, Gimbels equivalent of “Holiday Money,” which he promptly used to purchase some small item at Gimbels. He then turned around the next day and returned the item and received his refund in cash. Bingo. If he had made the purchase by credit card, the returns department would have simply applied a credit to his card balance. But Gimbels treated Holiday Money as if it were really cash. In effect, he had gotten a cash withdrawal on his Gimbels credit card, something that should never have been allowed. Mr. Thayer then went over to visit the Gimbels DP manager to let him know about the vulnerability. It was, indeed, a friendly rivalry.

Lesson Learned: Take the opportunity whenever possible to learn from your industry peers, even if they are competitors. Of course, no one should share trade secrets with competitors, but we can and should learn from one another in areas such as IT security, technical standards, and open source, where we can all mutually benefit for “the greater good.”

“I Just Want a Hot Steak”

Earlier, I mentioned that Macy’s DP department had its roots in a group called the Systems and Procedures department. The word systems here did not refer to computer systems but to the manual systems that ran Macy’s store operations. They spent a lot of time designing forms, filing systems, and procedures. So, when computers became commercially available, this department was the natural group to implement them to automate those procedures.

Macy’s DP department still had this orientation toward business processes when I joined almost 25 years later. For example, one day Abe told me an interesting story while we were having lunch down in the employee cafeteria. He pointed to employees paying at the cash register. He remarked that a few years earlier he was frustrated that there would typically be a bottleneck in front of the cashier and that, by the time he sat down to eat, his lunch was cold. So, he wrote up a formal suggestion to rebalance the serving lines and cashier lines to remove the bottleneck. Today, we’d call this lean thinking. Abe’s solution didn’t involve computers, but it greatly improved the process by getting employees quickly to their tables after being served.

Macy’s employee suggestion program included a reward program for suggestions that were accepted and implemented. Abe’s suggestion was soon implemented, but he refused the reward. He said something to the effect of, “It’s my job to improve processes. I don’t want a reward. I just want a hot steak.”

Lesson Learned: Despite all the advances in technology, enterprise IT is still all about thinking in terms of business processes. If you’re going to be successful, you have to be like Abe, who was reengineering business processes even while at lunch, at least 20 years before Michael Hammer coined the word.

Human Costs Unavoidable

But process improvement wasn’t always painless. Sometimes it automated people out of their jobs.

For example, when I first started at Macy’s, there was a department of about 20 women who produced daily flash sales reports using large mechanical calculators, as shown nearby. This group sat right next to our DP department.

One morning as I walked to my desk, I saw that this entire group was gone—all the women and their calculating machines had vanished. I asked Abe what happened. “We wrote a system,” he replied. He didn’t say it in a cold way, but as if to say, it’s too bad but we have no choice.

The impact of the new system was great. It was much faster and more accurate than human calculators. Instead of tabulating data from paper receipts, data from cash registers could now be collected and fed into the IBM mainframe. This allowed daily sales to be reported more quickly, greatly improving management decision-making. If Macy’s didn’t do it, Gimbels surely would and no doubt did so.

Interestingly, Macy’s was the last place where I saw a human elevator operator. He was a kindly old man, who was still there when I left a year or so later. His job, of course, eventually was automated.

So, yes, there is a human cost. But as these jobs were being destroyed, new jobs, like mine and the rest of our team’s, were being created. As a result, unemployment today is actually lower than it was at the time Abe automated the flash sales department.

Lesson Learned: Today, robotics, machine learning, and other new technologies continue to automate jobs out of existence. Is there a human cost? Of course there is. Do workers need to be retrained? Yes. But if history is any guide, the labor market will adjust. Color me optimistic.

Equipped for the Next Chapter

After two and a half years, I was a pretty good COBOL programmer and passable in IBM assembly language—enough to qualify me for my next job, which involved a move cross-country.

Remember Richard Miles, the vice president whom I interviewed about Holiday Money the first week on the job? He gave me a job recommendation that proved critical. But more importantly, I was equipped with important lessons learned in what it means to be a business analyst, understanding the business through the eyes of the users, and helping them improve business processes, themes that continued through the rest of my career.

For the next chapter, see: What I Learned at TRW Credit Data about Enterprise IT.

End Notes

[1] My wife’s office was at the end of a long dark hallway that connected it to Bellevue Hospital, founded in 1736, making it the oldest public hospital in the US. At the time (and still now), it included a prison ward for treating inmates and a psychiatric ward. “You are a candidate for Bellevue” remains a family saying of ours to this day.

[2] The 24 programmer/analysts, like me, sat in two rows of 12 desks each, back to back, with no cubicles, no partitions. We were practicing open offices before they were a thing.

[3] Unlike the rest of us, Mr. Thayer, as the director of the department, had the only closed-door office. The two managers under him, including my manager, Jack Krigstein, had little cubicles, each at the tail end of each row of programmers (i.e. they were looking at our backs). It was tight quarters. It was also an austere environment. Forget free snacks, we didn't even have free coffee, or any coffee in the office, for that matter. A couple months before I left, the whole department chipped in to buy a coffee maker, but only used it for hot water to make instant coffee.

[4] There was an interesting wrinkle to the specification. The preprinted forms were designed “two-up,” meaning that as the form passed through the printer, the program needed to print them with two customers side by side. But to take advantage of bulk mailing rates, it would also need to print them in zip code sequence. The way the splitting and bursting machine worked, it would need me to export the necessary data and count the number of customers, then sort the file in zip code sequence and split it exactly in half, then merge the second half side-by-side with the first half so they could be printed two-up. So, it was not a trivial first assignment.

[5] Program coding back then was all handwritten. Look down those two rows of desks and you wouldn’t see a single desktop computer, not even a dumb terminal. We wrote all our code in pencil, on standard programming forms. If you wrote out a program and then decided to reorganize it, you got out a scissors and scotch tape (literally, a cut-and-paste). We turned in our handwritten forms to keypunchers, who punched them onto 80 column card stock, which we would submit to the computer room for compilation. A few months after I was hired, we got direct access to the card punch machines, which saved us quite a bit of turnaround time for code changes. Source code libraries were just around the corner, but at this time we filed the physical card decks in cabinets, along with the compilation printouts and the generated object code (also on card stock).

[6] I have not been able to find an example of Abe’s style of flow-charting anywhere on the Internet. This must have been a style from the very earliest days of programming. IBM later popularized a more complex version with various shapes, each of which had a particular meaning. In my opinion, Abe’s style was simpler and more useful, and I reverted to it from time to time even years later.

[7] Today, nearly no one would dream of writing a custom A/R system. But this was standard practice back then. When I joined Macy’s in 1974, every single business application in the company was custom-written, even payroll and general ledger. I didn’t encounter my first commercial software package until four years and two jobs later.

[8] Although the IBM 360 was a tremendous step forward from previous generations of NCR and IBM mainframes, core memory was just 125K. That’s kilobytes, not megabytes. So we were always looking for ways to optimize our code and save a few bytes here or there. A few years earlier, when memory was even more constrained, one programmer had come up with a unique way to reduce memory requirements for a batch program. Instead of including the end-of-run logic as part of the program, he compiled that logic and stored it as executable code in the last record of the input file, which was on tape. When the program got to that record, it would load the record into core memory and branch to it to execute the end-of-run logic. It was a brilliant solution, but it was extremely difficult to maintain.

Image Credits:

1: Macy's storefront today, Paulo JC Nogueira

2: Roller skating clown, Diariocritico de Venezuela

3: Example of bubble chart format, from author's memory. (Not an original of Abe's).

4: Burroughs Adding Machine: Chris Kennedy.