Sunday, June 13, 2021

A Personal Experience of Lateral Thinking

Pluto, dog
I missed the news earlier this week of the death of Ed de Bono. De Bono was the father of lateral thinking, a framework for creative thinking. Wikipedia has a decent outline of his ideas and influence. 

De Bono was one of the authors that most influenced my consulting career. I adopted many of his tools, most of them quite simple, in analyzing business problems and coming up with creative solutions. The tools are especially useful in facilitating groups. I only regret that I have not applied his methods more consistently in client engagements and even in my personal life. 

One of my favorite tools is the random word stimulation, which is great for brainstorming sessions. Simply put, when you are trying to come up with ideas that are "outside the box," you generate a random word (e.g., pick it out of a dictionary) and use that word as a jumping off point to come up with new ideas. The key, as always with brainstorming, is not to look for ideas that make sense, just generate as many as you can.  When you run out of ideas, do another random word, and another. As with any kind of brainstorming, no judgment of the ideas is allowed.  Save that for a later step. 

In explaining this method, I like to point to one experience from a consulting engagement many years ago. My late business partner, Dan Husiak, was leading a client engagement to develop a new business strategy for a division of what was, at the time, one of the largest health plan providers in the U.S.  We had scheduled a brainstorming session the next day, and Dan assigned me to facilitate the session. The objective was to come up with some new out-of-the-box ideas for new products or lines of business. 

I suggested we use random word stimulation and explained how to do it.  Dan didn't like it. 

Dan: You mean you just pull out some random word, like "Pluto?" 

Me: Okay, good example. Do you mean Pluto the planet, or Pluto the cartoon character? 

Dan:  I don't know, just "Pluto." 

Me: Okay, let's think about this. Pluto the planet. It's small, it's far out. We need far-out ideas. Not much there. Now, Pluto the dog. He's a dog. He's an animal. He's a pet.  Hey, we can offer health insurance for pets! 

That was enough to let Dan give me permission to try it the next day. 

The brainstorming session was a success. In fact, at the beginning of the session, I used the "Pluto" exercise as an example of how to use random word generations. After a couple of hours, the client project team had come up with a number of promising new ideas--enough for us to start evaluating them the next story.  

The best part of this story is that at the end of the session, the top executive for the firm's Medicare HMO product line came up to me and said, "I want to talk to you about that pet insurance idea. You know our seniors love their pets, and pet ownership correlates with positive outcomes. We should look into how to offer a pet HMO."  

Keep in mind, this was before health plans for pets were a widespread practice. 

Thinking tools like random word generation are not only effective in creative thinking and problem solving. They are also fun. 

Ed de Bono will be greatly missed. But fortunately he left the world with a long list of books, courses, and other publications for learning how to think.  A good place to review them is his website. 

Thursday, March 18, 2021

Enterprise Buyers Not Looking for a One-Stop Shop

There's been an interesting discussion on Twitter over the past few days, which I started with this deliberately ambiguous tweet. 

IMO, very few enterprise buyers are really looking for a "one-stop shop." 

As intended, that brought out replies from several friends and associates, such as Vijay Vijayasankar, Oliver Marks, Holger Mueller, Jody Lemoine, Shane Bryan, John Appleby, and others. 

So, what did I learn from the dialog? 

First, I was thinking back to client meetings I've sat through over the decades, where business leaders positioned "one-stop shop" as a key element of their desired strategy. 

In other words, in the market we serve, customers are typically looking for 10 things.  But today, we only offer seven. If we can offer all 10 things, we can become a one-stop shop! Customers will not have to go anywhere else but will have the convenience of having us satisfy all their needs. 

In enterprise software, this might translate to an ERP system vendor attempting to offer a CRM system or supply chain management suite, or product data management, or a host of other complementary products. Invariable, because these systems take years to develop from scratch, in practice this means acquiring those complementary products. It may also mean offering other elements of a complete solution, such as a development platform, tooling, system integration services, even databases or hardware. 

I don't know if Oracle ever used the term "one-stop shop," but it certainly behaved as if it had. It has been on a multi-decade acquisition spree, not only in business applications, but also in databases (its roots), infrastructure software (BEA), even hardware (Sun). To be fair, it also plowed profits from those products into new development, such as for its Fusion cloud applications. And it is now competing with Amazon for cloud infrastructure services. It is a poster child for the one-stop shop. 

SAP has had its own version of the one-stop shop, acquiring a variety of systems (Holger calls some of them the seven sisters). It also built its own proprietary database, and it also has its own development tooling. 

What About One Throat to Choke? 

One can imagine why such a strategy might be attractive to technology sellers.  But is it attractive to technology buyers? 

I say, no.  In decades of consulting, I don't think I've ever heard a client say, I just wish I could buy everything I need from a single vendor. What I need is a one-stop shop. 

But isn't a one-stop shop the same as "one throat to choke?" I say no. One throat to choke means that in a system implementation, for example, there is a prime contractor or service provider ultimately responsible for delivery. If another partner in the deal is not meeting its commitments, the prime contractor or service provider serving as overall program manager is responsible.  It doesn't mean that there is only one service provider or vendor in the deal. 

What About Integrated Suites? 

Holger asked, "Are you saying that [integrated] suites are done?" Not at all. But I have two responses to this. First, many integrated suites are anything but.  Especially if, as noted above, the vendor built its suite from piece parts that it acquired over time. It takes years to integrate software acquired from various sources. So, buying from a vendor attempting to be a one-stop shop does not ensure you are really getting an integrated suite. 

Second, I have seen very few large deals where there was only a single software provider in the deal. There are almost always complementary products whether they be for sales tax reporting, factory data collection, data analytics, or countless other niche requirements. 

Third, no IT organization's application portfolio only has software from a single vendor, not even a handful of vendors. Even small companies buy software from dozens of vendors. There is no one-stop shop in enterprise software. 

What About Application Rationalization? 

But what about vendor consolidation? Maybe one vendor isn't reasonable, but isn't it a good idea to limit the number of software providers and rationalize the applications portfolio?  Certainly, many companies need to consolidate applications, especially if they grew through mergers and acquisitions and now have two, three, or more ERP systems, for example. 

But that does not mean they need to only buy from one vendor. 

Vendors love to talk about vendor consolidation, as long as the surviving vendor is them. They call this gaining in their "share of wallet," as in the buyer's wallet. 

In my view, when it comes to vendor consolidation you can have too many vendors and you can also have too few. You don't want to have so many vendors that you have redundant types of systems. On the other hand, you don't want to have too few vendors to the point that they gain leverage over you.  

To this point, I've heard of customers engaging in multi-year programs specifically to reduce dependence on certain Tier I vendors, as they become too powerful and attempt to engage in wallet fracking, as my friend Brian Sommer calls it. 

Is there a way to have the benefits of integration and applications rationalization without becoming overly reliant on a single vendor?  I think there is.  Modern cloud systems have become API-oriented. And to be fair, the major vendors, even those aspiring to a greater share of wallet, are building with this model. They have to, if they want market acceptance. Cloud leaders, such as Salesforce, do it by providing a platform that partners can write to, even leveraging Salesforce objects, to provide that integration. Oracle's NetSuite offers a similar capability. Cloud ERP vendors, like Acumatica, Plex, and Sage Intacct are very integration-friendly. Oracle's cloud applications and SAP's offer open APIs, as does Workday. Microsoft has similar capabilities. 

If this is the future, then maybe vendors will give up the strategy of the one-stop shop. 

Wednesday, March 10, 2021

Deploying Low-Latency Applications in the Cloud

Cloud has become the preferred deployment option for most categories of enterprise systems. But conventional wisdom is that some systems that require low latency and a high degree of system availability, such as warehouse management systems (WMS) or manufacturing execution systems (MES), are best deployed on-premises.

The argument is that response time over the Internet is never as fast as over a local area network and that such systems cannot tolerate any level of unscheduled downtime inherent in using a cloud application. 

Nevertheless, cloud systems are invading even this category of software. Although still in the minority, there are some vendors providing such low-latency applications as a cloud service. 

One example is Plex Systems.  And, interestingly, it is not a new example. 

Read the rest of this post on the Avasant website: Deploying Low-Latency Applications in the Cloud.  

Tuesday, August 18, 2020

Why Would Oracle Want TikTok?

TikTok Logo
Oracle is reportedly in talks to acquire the certain operations of social video service TikTok. 

I'm hearing through the back channel that the move is not being well received within Oracle itself this morning. 

From the Verge

Oracle has expressed an interest in acquiring TikTok, according to the Financial Times, giving Microsoft a potential competitor in its bid to control the Chinese social video app in the US. Larry Ellison’s enterprise software giant has reportedly held preliminary talks with TikTok’s parent company ByteDance already, working with venture capital firms including General Atlantic and Sequoia Capital, and is “seriously considering” acquiring its business in the US, Canada, Australia, and New Zealand.

So why would Oracle acquire a business that is so far out of its market space? 

I've heard speculations from various quarters. It could be motivated by a desire to leverage TikTok's user data to enhance Oracle's marketing products. It could be motivated by a desire to get into a consumer business. It could be motivated by a desire to hurt Microsoft--something that would fit Ellison's competitive nature. 

There's one more possible motivation I haven't heard mentioned, and that is to get TikTok's huge workload for Oracle Cloud Infrastructure (OCI). Oracle's market share lags far behind Amazon, Microsoft, and even Google's. There is a bit of a chicken-and-egg problem facing Oracle, however. Cloud infrastructure providers need large workloads to realize economies of scale, making them price competitive. But how can Oracle achieve that scale? One way is to buy the workloads. And what bigger workload than a video-sharing service? 

This is likely the reason that it offered a deal to host some of Zoom's workloads on OCI. So, it might also be the primary motivation for Oracle to pitch for TikTok. 

Anyone with me?  

Saturday, August 08, 2020

Impact of the Coronavirus Pandemic on IT Budgets in 2020

Over at Computer Economics, we just published our annual IT Spending and Staffing Benchmarks study, now in its 31st year (click to download the free executive summary). 

This year, however, there was a bit of a complication: The COVID-19 pandemic hit right in the middle of our survey period. So, in order to measure the impact of the pandemic, we added special questions to our survey and also went back and re-surveyed those who had already responded. We published the results in a special supplemental report: Impact of the Coronavirus Pandemic on IT Budgets in 2020. The results are interesting, and we plan to repeat the survey in the coming weeks.  

In addition, Dave Wagner and I gave a free webinar to present a summary of the results of both reports. Click the image below to watch the full replay. 


Wednesday, September 18, 2019

IFS and Acumatica Living Together in the ERP Space

Photo Credit: Jon Reed, Diginomica
When does the relationship between two tech vendors look like a merger but is not actually a merger?

For all intents and purposes, that’s exactly what just happened with two players in the enterprise resource planning (ERP) industry. EQT Partners, a global private equity fund, recently finalized a deal to buy Acumatica. Although EQT already owns another ERP firm, Swedish-based Industrial and Financial Systems AB (IFS), it is not merging them. Rather, the two firms will work closely together, while remaining separate entities under the same EQT holding company. EQT’s Jonas Persson will serve as chairman of both companies, and IFS CEO Darren Roos (pictured above, on the right) will assume a seat on Acumatica’s board.

IFS may not have the name recognition of SAP, Oracle, or Microsoft, but at about 10,000 customers worldwide, IFS is much larger than Acumatica. It counts in its arsenal corporate giants such as Toyota, BMW, Pepsi, John Deere, and the largest container ship company in the world, Maersk.

It’s not that a merger was not on the table. EQT’s acquisition came after IFS considered buying Acumatica outright, Roos said recently at an analyst event. After carefully considering the situation, EQT decided that IFS and Acumatica are different enough that a different strategy was needed, to keep the two firms separate.

For its part, Seattle-based Acumatica has grown to more than 5,200 mostly small and midsize customers in 11 years. It is known for packaging its products into industry “editions.” Each edition marries Acumatica’s horizontal functionality (primarily financials, distribution, and customer management) with industry-specific modules, such as commerce, construction, manufacturing, field service, and distribution. Acumatica sells these editions through a network of value-added resellers (VARs).

Read the rest of this post on the Strativa blog:
IFS and Acumatica Living Together in the ERP Space

Wednesday, August 28, 2019

The Use and Misuse of PaaS

One of the key advantages of modern cloud systems is that they often come with rapid development platforms that allow the vendor, partners, and even customers to build extensions and customizations to the system without affecting the underlying code or architecture of the base system. These are generally known as Platform as a Service (PaaS).

Examples include the Salesforce Lightning (formerly platform, the SuiteCloud platform of Oracle’s NetSuite, Acumatica’s xRP platform, Sage Intacct’s Platform Services, Microsoft’s Power Platform, and many others.

However, as with so many good things in life, PaaS can be used and abused.

Read the rest of this post on the Strativa blog:
The Use and Misuse of Platform as a Service 

Wednesday, July 17, 2019

The Benefits of Business Process Framing

In selecting and implementing a new enterprise system, business leaders have learned the importance of evaluating business processes. “Let’s not make this an IT project,” they say. “Let’s really understand our current business and our vision for the future.” Without a doubt, this is right, and we encourage our clients to do exactly that.

However, business leaders often think that this means they should begin with detailed process mapping of their existing processes. “Let’s have someone come in and map all our business processes,” they say.

At first glance, this seems logical. If we want to define our business requirements, what better way than to map our “as-is” processes?

Why is this not a good idea? There are at least three reasons.

Read the rest of this post on the Strativa blog: The Benefits of Business Process Framing

Friday, June 28, 2019

Time for a Declaration of Independence from Software Vendors?

When it comes to enterprise IT, every so often we begin to notice things that cause us to question our basic assumptions. The latest is about the role of commercial software.

The traditional advice for companies is that it is best to standardize on a commercial software vendor for the core of the applications portfolio. It might be a major vendor, such as SAP, Oracle, or Microsoft, or it might be any number of other providers. Custom software should be the exception, not the rule, whether for unique industry requirements, or for modifications and extensions to the core system. The more you can rely on a commercial software vendor, the better.

We’ve been giving this guidance for decades, whether for on-premises systems or with cloud-based systems.

Nevertheless, some of our clients are starting to rebel against the conventional wisdom by developing more of their own software in-house. Moreover, they are not doing it just on an occasional or exception basis or for niche applications. They are doing it for domains where we traditionally assumed that commercial software was the natural choice.

Read the rest of this post on the Strativa blog: Time for a Declaration of Independence from Software Vendors?

Wednesday, June 19, 2019

What I Learned at Macy's about Enterprise IT

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.

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, Gimbel's. 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 Hospital1, 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 desk2 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 office3 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 specification4, and I thought I could write the code5 based on Mr. Thayer’s verbal instructions. But first he told me, “Now, put on your sports jacket, and go down and talk to the accounts receivable director 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 business manager about his requirements. I’m pretty sure that Mr. Thayer knew it wasn’t necessary to have me interview the A/R director, and, as expected, the meeting was uneventful. But Mr. Thayer was teaching me my first lesson.

Lesson Learned: 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 title of programmer/analyst, not just programmer. Understanding user requirements was part of the job from your first day. Here’s the first way things have not changed.

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 often 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 nearby6.

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 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 system7 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 3608.

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 Gimbel’s? 

My first programming assignment was successful. After I had finished, Mr. Thayer told me a funny story. As noted earlier, Gimbel’s department store was still across the street from Macy’s, and the two were rivals. In fact, “Does Macy’s tell Gimbel’s?” 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 Gimbel’s 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 Gimbel’s credit card. As a result, Mr. Thayer had received, in the mail, Gimbel’s equivalent of “Holiday Money,” which he promptly used to purchase some small item at Gimbel’s. 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 Gimbel’s treated Holiday Money as if it were really cash. In effect, he had gotten a cash withdrawal on his Gimbel’s credit card, something that should never have been allowed. Mr. Thayer then went over to visit the Gimbel’s 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, Gimbel’s 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 that A/R director 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.


1My 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.

2The 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.

3Unlike 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.

4There 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.

5Program 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).

6Interestly, 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.

7Today, 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.

8Although 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.