Interfaces publishes short essay articles and essay reviews connecting the history of computing/IT studies with contemporary social, cultural, political, economic, or environmental issues. It seeks to be an interface between disciplines, and between academics and broader audiences.
2020 (Vol. 1) Table of Contents
Malinda Dietrich, University of Colorado, Boulder
Abstract: In 2020, video telecommunications seem ubiquitous. Between work and play, many people use a range of software to connect them with other people all around the world. This short essay begins to explore how we arrived at this seemingly universal technology by exhuming a failed technology: AT&T’s Picturephone. Through this historical exploration, we will come to see that infrastructure and culture are closely related, and that future work must be done to explore the social inequities that become apparent.
Regardless of how commonplace video calls are now, they are the result of continuous iterations of a failed technology from almost half a century ago called the Bell Laboratories’ “Picturephone.” First showcased during the 1964 World’s Fair, the first Picturephone demonstrated how people on a call could see one another, at 30 frames per second and in black and white, on small screens (“Mechanical ‘Brains’, Lasers”). The cylindrical device housed a screen on one end and connected to a handset that allowed the user to control the screen (Gertner). Using this technology, two men—one in New York and the other at Disneyland in Anaheim, California—completed the first transcontinental video call which lasted about ten minutes (Gerber; “Television Phone Used”). After the demonstration, visitors waited in line for a turn to use the machine and speak on one of the picture phones in one of six booths (Schnaars and Wymbs; see Figure 1). After the World’s Fair, market researchers conducted 700 interviews with individuals who attended the World’s Fair and used the Picturephone (Gertner; Schnaars and Wymbs). Most users rating the service well, and criticism focused on design features like the inability to turn off the video or adjust the height of the device (Schnaars and Wymbs). Bell Laboratories hoped that this would ignite widespread interest in the device, anticipating a Picturephone would live inside the homes of most people by the 1980s (see authors in the Bell Laboratories archive).
Scholars who have highlighted the failure of the Picturephone point to the many infrastructural issues (see Gertner; Lipartito; Schnaars and Wymbs). It was expensive to lay supplemental wires to transmit a video signal, increasing the price of the service, and meant that picture quality was poor. Missing from these accounts of the Picturephone is an understanding of infrastructure’s relationship to culture. Kenneth Lipartito begins to create this tie by focusing on the material and discursive formations of the Picturephone. His work focuses on the rhetoric of failure, using the Picturephone as an example (Lipartito). The technology worked from an engineering perspective; however, Bell had not considered that this service did not fill a consumer need, or that it needed a critical mass to take off (Schnaars and Wymbs). In other words, just because the infrastructure works, did not guarantee the popularity of this technology; therefore, this article tries to use the Picturephone as an historical artifact that allows us to speak through cultural relations to infrastructure.
“Picturing” the Future of Telecommunications in the Late 1800s
The idea of a Picturephone can be traced to around the same time that the telephone was taking off. On December 9th, 1879, George du Maurier published an illustration of “Edison’s Telephonoscope” in Punch magazine, in which two individuals are depicted using a technology that resembles a phone, megaphone, and television combined to communicate (see figure 2). While the reading of this image is contested—some arguing this image is a satire of Thomas Edison and his future inventions (Roberts)—others have projected that this image resembled what a video phone or a television would look like almost 100 years later (Burns). While this image could be read as one of the earliest conceptions of a video telephone, it was not until the 1920s that the first formal attempts at video conferencing began.
Video telecommunication, at the most simplistic level, requires sending images along with a telephone signal. By the 1920s, the cables and wires used for the telegraph as well as the telephone had been installed. Alexander Graham Bell had established the companies that would eventually become American Telephone and Telegraph Company (AT&T) in 1884 (“The History Brands”). The research branch of AT&T, Bell Laboratories, would work with one of the engineers and inventors of the first mechanical television (which was released in 1926) to complete the first video conference call in 1927 (Hanhardt, see also McGoogan). This call, a two-way audio connection with a one-way video connection, connected Secretary of Commerce Herbert Hoover and other officials in Washington, D.C., with AT&T president Walter Gifford in New York City (Turi). A few years later, in 1931, Bell Laboratories held the first public demonstration of a two-way videophone (Guernsey). The system for this demonstration used early television equipment and a closed circuit (Turi). Due to the Great Depression, further iterations of video telephones stalled; the technology lacked efficiency and reliability, and it needed further development that required more funding (Guernsey).
On December 23, 1947, the transistor was successfully demonstrated at Bell Laboratories (Shampo et al.). The transistor became an integral part of many (if not all) modern electronic devices—it served as an amplifier for power, removing the need to rely upon display tubes, as well as a switch for digital devices. Following this invention, and a few years to figure out how to implement it, the 1950s brought in more instances of images sent over telephones lines. In 1955, the Mayor of Palo Alto called the Mayor of San Francisco using a videophone developed by Kay Lab of San Diego (“Gawkie-Talkie”). According to a Chicago Tribune article, this video phone was anticipated to take off in the 1960s, particularly in factories and hospitals. About a year later, hospitals and the U.S. defense department demonstrated interest in X-Ray pictures being sent over the phone and Bell Labs developed their first phone that transmitted pictures along with sound (“Sending X-Ray Pictures”; “Phone that transmits”). The phone, not introduced as the Picturephone yet, included a 2-inch by 3-inch screen and utilized a pair of ordinary telephone wires to display one picture every two seconds (“Phone that transmits”; “Scientists See Picture-Phone”; Gould).
AT&T tried to use the wiring and other infrastructures available to them (and that they held a monopoly on) for the Picturephone. To Geoffrey C. Bowker and Susan Leigh Star, “good infrastructure is hard to find” (p. 33)—the easier the systems are to use, the more the material systems recede into the backgrounds of our minds. On one hand, the Picturephone demonstrated this theorization of infrastructure: tens of thousands transistors went into the creation of the picture telephone (Gertner, p. 190), while now, billions of transistors (now at the size of ten nanometers and continuing to grow smaller) go into a single central processing unit (Gertner, p. 209). On the other hand, using a Picturephone was clunky and not intuitive enough for the use in people’s homes.
Picturephone Model I: Not Your Average Payphone or Telephone Booth
A few months after the Picturephone’s appearance at the World’s Fair, Lady Bird Johnson assisted AT&T in kicking off its commercial Picturephone service, to make a call from Washington, DC to New York City. Mrs. Johnson spoke for five minutes to Dr. Elizabeth A. Wood, a scientist from Bell System’s laboratories, on a screen 4⅜-inches by 5¾-inches (“Picture Phones Go”; see figure 3). Unlike at the World’s Fair, individuals did not have to sit completely still to be seen by the other individual.
James W. Cortada, Senior Research Fellow, Charles Babbage Institute, University of Minnesota
Abstract: IBM was an early practitioner of remote working, beginning in the 1890s, but expanding this way of working in the 1980s. Customer engineers, programmers, systems engineers, salesmen, and consultants participated. Mobile work posed its own operational problems but offered benefits for improved service, productivity, and employee morale. However, its motives and practices remained controversial.
With the pandemic in full swing this spring, many people began working from home, or elsewhere other than their office. The opulent campuses in Silicon Valley emptied and to the shock of many IT people it was a radical change. As of March 2020, it appeared that five million US employees worked from home, representing 3.6 percent of all labor. Other data suggests that up to 43 percent of office workers sometimes work from home, which sounds more realistic than 3.6 percent of all labor. IBM recently bragged that hundreds of thousands of its workers worked remotely, but then within a couple of months that many would be brought back into offices. IBM had made a similar announcement in 2017 after having bragged about how extensively its staffs worked remotely. But IBMers have been doing this since the 1890s, before they became C-T-R in 1911 and renamed IBM in 1924, and long before the Internet, iPhones, or clunky laptops. So, it appears we need some history.
Providing Onsite Service
IBM has always been an ecosystem of different types of workers: headquarter office employees, programmers and engineers in research laboratories, factory workers, customer engineers (CEs—they installed and repaired equipment and software), sales personnel, and consultants. CEs (under different titles over the century) worked since the 1890s wherever customers had tabulating equipment, later computers. About once a week they came to an IBM office to do their paperwork and meet with their managers. That continued right through the twentieth century. In research for this article I queried retired CEs. One who had started in the 1950s explained that his “tech support,” i.e., how he interacted with “Dispatch” and his manager, was “a phone booth.” Until the 1980s, they filled out “IRs,” on cards, which were “incident reports” with information on the nature of their work, repairs, customer name, and so forth. For decades, CEs kept Dispatch informed of where they were working, received instructions of where to go next, could check in to see about the availability of parts, and to otherwise keep these dispatch centers informed.
Then in 1983, the Field Engineering Division introduced the Data Communication System (DCS, Motorola KDT800 terminal), better known by several tens of thousands of employees as the “Brick,” because it looked like one. Built by Motorola operating in a radio network run by that company, it worked well and was used much like a tablet, continuing to minimize trips to the office, except to pick up parts and attend monthly meetings. In 1997, Motorola introduced a new generation of the machine. IRs and all manner of Dispatch and management communications were done remotely.
California Surfing on a Terminal
In 1979 a different chapter in IBM’s mobility history began when its laboratory at Santa Teresa in Silicon Valley gave five employees terminals to work at home. Productivity and morale was high, the technology functioned, and other lab employees there and in other locations began doing the same. By 1983, an estimated 2,000 employees in the U.S. worked a combination of at office and home. Their ability to program remotely expanded through the 1980s, facilitated by faster dial-up lines over the years and the ability to attach modems to PCs during the second half of the decade. Simultaneously, IBM expanded its e-mail network (PROFS) worldwide, with incremental ability for employees to access e-mail from home. Anecdotal evidence suggests programmers liked working remotely. Some worked at an IBM facility, but also had access to files and mainframes from home.
On critical projects, such as with product development and support, technical staff found it useful to have access to mainframe-hosted files after hours to troubleshoot issues at night or on weekends using PCs, initially with dial-up connections. That sped up analyses of problems, instead of waiting to do so after driving back to a plant location, such as at Boca Raton, Florida (home of PC development in the early 1980s) or to the Rochester, Minnesota facility, where additional collaboration on PC and other related issues required coordination between the two sites. They built on the experiences of programmers of the 1970s at the Palo Alto, California site that had used TTY terminals to develop APL.
But What About the Sales Force? Weren’t They Mobile?
In the 1910s, IBM had sales facilities called branch offices that looked more like retail operations, where customers came to learn about products. By the end of the 1920s and extending to the 1990s, branch offices existed where sales staff had either a desk in “bull pens” or offices, but they spent only about a third of their time in these facilities. The rest was spent traveling from customer to customer, working out of their buildings, communicating to other IBMers via telephone, later also with their IBM-issued laptops (1990s), because in their trade face-to-face communications with customers proved crucial. They and their customers also visited IBM’s education centers and labs to learn about new products and applications. Every manufacturing site entertained its customers this way. So, salesmen had considered themselves remote workers for nearly a century.
As branch offices were dismantled in the 1990s, replaced with hotel-styled workspaces that became popular with many companies, sales staff came into IBM facilities less frequently. They came in to pick up their mail, use a conference room to host meetings with customers, and kibitz with colleagues. By then, they were interacting with their managers via telephone, rarely in person. By the end of the 1990s it was not uncommon for a salesman or consultant to say that they had not seen their manager face-to-face in six months, although communications via telephone and e-mail were frequent, at least once a week. That reality still exists today. The lower in an organization one was the more likely they worked remotely without a desk or office to claim in an IBM building. In all eras, by the time one became a second line manager they had an office, although even that practice declined in the early 2000s.
Big Blue Goes All Out With Mobility
In the late 1980s IBM entered a period when revenues and profits began declining sharply, forcing management to cut expenses. The Real Estate Division, which was responsible for building factories, offices and laboratories and for renting space was put under enormous pressure to sell-off some, which it did. But what does one do with all those employees who used to go to large office towers in Paris, New York, Chicago, and elsewhere? The problem involved field personnel—salesmen, systems engineers, their management, and their administrative staffs. In the United States, beginning slowly largely in the Midwest, customer-facing employees and their administrative staffs were issued PCs, and IBM began paying for their slow dial-up lines. Some of these lines were also set up in customer facilities. One employee working with Kodak in 1994 recalled, “When I started out working from home IBM and TSS (a Kodak-IBM joint venture) offered us office furniture, printers, computers, paper and paid for by the company along with reimbursements for Internet access and voice telephone home office charges.” Later, the company was less generous. Salesmen, systems engineers, and consultants began working remotely in the early 1990s and by the end of the decade tens of thousands, rarely coming into an IBM office.
It worked again. People’s commutes declined; time spent driving to work often was now devoted to doing IBM’s. One employee recalled that everyone’s productivity “went through the roof.” Work/life balance improved, while managers who initially thought less work would be done learned that the opposite was true. Prior to going remote various surveys of how people spent their time at work reported that a third was consumed by internal meetings and paperwork. Meetings converted to conference calls, which all had to be scheduled, so it seemed the number declined, while remaining paperwork was sped up with email, automation, and online processing. IBM was able to discard over $2 billion in property, some 58 million square feet.
But there was an ugly side to the exercise. One employee involved in some of its earliest iterations explained: “As someone who was involved in IBM’s Mobility program when it was begun around 1993, the entire focus was to equip customer facing folks with the tools, laptops, cell phones, etc. to work from customer, office and home as needed, but it was never intended as a full-time work-at-home program. But when Real Estate found out how much savings $$ they could [gain] by ending leases and selling buildings they forced the issue.” He added, “after IBM booked all those Real Estate savings, they realized they had created something that disconnected IBMers from the Company, community and teams, and they tried to rectify that, but it wasn’t very successful.” Some employees, however, reported no loss of loyalty or connection to IBM. Many found working remotely a positive experience, as one put it, “It was good for me professionally as well as for my family.”
New Era, Consultants and More Mobility
When IBM entered the consulting business in the 1980s, and then in 2002 acquired 30,000 employees from PriceWaterhouseCoopers (PwC), the field force was well over 200,000. All were armed with laptops loaded with consulting and sales tools, other software tools, access to the Internet and to IBM’s myriad internal databases, and email. (My laptop from the 1990s above.) By the end of the 1990s, there were tens of thousands of employees who rarely—if ever—entered an IBM office, other than during the first couple of weeks of initial employee onboarding activities. By 2009 IBM reported that, “40 percent of IBM’s some 386,000 employees in 173 countries had no office at all.”
IBM learned much during its first three decades of the modern era of working remotely. Employees put in as many hours (or more) as they had in offices and plants, often diverting time spent commuting now to work; hence the company got more hours from their employees without IBMers feeling overworked. They worked in more optimal ways; morning people by 9:30 had been “at work” for three hours; other employees were night owls and so they were working at midnight. Most loved the 20-second commute from their kitchens to their “IBM office.” They could attend their children’s school events and be productive because they had more control over their calendars, their time. It worked. IBM lost some of the spontaneous serendipitous opportunities to convene impromptu meetings to banter around new ideas, although that could take place; it just had to be scheduled more than before. One had to be proactive, but also to expect imagination.
Management had much more to learn, however. People needed job descriptions, incentives, and appraisals that valued self-reliance and personal commitment to their jobs. So, hiring self-starters proved crucial, not simply bright people who needed to be told what to do. Those that did not fit the profile disliked this mode of work, often feeling isolated, and so drifted away. Management let it happen. Most employees adapted to the new way of working. Consultants from PwC came from a culture of working remotely at client locations. Everyone needed digital plumbing: high-speed internet access paid for by IBM (not employees), powerful laptops and state-of-the art smart phones. The company learned to budget for these, and whenever some manager did not, employees rightfully complained, or quit. It had to be a commitment made at the top of the firm, a lesson the company partially ignored in the 2010s when it went through another round of challenging business times.
Managers had to host online events to maintain community. I used to hold virtual staff meetings at a time agreed to by my teams, which I insisted we would hold “whether we needed to or not.” Every one of those staff meetings was always packed with things to talk about. My colleagues in management had the same experience. When online face-to-face meetings became available in the 2000s, these became more relevant, impactful, and employees looked forward to these. We are after all social creatures. It proved important to use such events to maintain cohesion, group spirit, and teaming.
In 2012 IBM entered a new period when revenues started to decline every quarter with the exception of one until 2020. Profits shrank, too, in the post 2017 period. To protect its balance sheet IBM went through relentless rounds of reducing operating costs. These involved attempting to sell off less profitable lines of business, such as the PCs and DASD, to dispose of buildings (largely factories), and to continuously lay off employees. An estimated 100,000 were laid off or otherwise pushed out of the company since 2010/2012. Nowhere was this more evident than among the ranks of the CEs, salesmen, systems engineers (now called IT architects), consultants, and administrative staffs. Factory workers were disposed of through sales of factories with bodies and buildings.
Another form of remote work that began in the 1990s and expanded in the 2000s receives little attention in discussions about mobile work. It is the wholesale movement of tasks from one country, or division, to another, famously Indian Help Desks at Microsoft, IBM, and other companies that come to mind. Labor costs were less in India—often 80 percent than in more “advanced” economies—and telecommunications were available and cheap. So, product development and customer and employee support services moved incrementally out of the U.S. and Europe to India. IBM India went from several thousand employees in the early 2000s to a rumored (never officially announced) 150,000 within a decade, and now closer to 100,000. Centers of Excellence, while still physical locations as they had been since the 1980s, interacted with customers and other IBM divisions more remotely over time. IBM was able to reduce its workforce population in the U.S. while still servicing its American markets, although often American IBMers and customers complained about eroding quality of support. Several tens of thousands of American workers were displaced between the late 1990s and the 2010s though this process. At IBM India, however, employees worked in cubicles on IBM campuses.
New Times New Issues
An important component of IBM’s workforce “rebalancing,” announced in 2017 involved forcing some groups of workers to stop working remotely, initially marketing and communications staffs. They were given the option of reporting to work at offices, often in other cities, which would require them to move their homes and families, normally at their own expense. If they chose not to do so, often within 30 to 60 days, they were considered to have “resigned” from the company. The strategy was implemented in waves between 2017 and the present, with the result that many employees in their ‘40s and ‘50s left IBM, rather than upset their personal lives. One press report stated what many IBMers were saying on their websites that this move back to the office was “a veiled method of shedding workers.” (Vassel, 2020). IBM said it was to improve productivity and collaboration for improved innovation. The media reported that various studies essentially demonstrated letting employees work wherever suited them improved performance and productivity. In 2017, IBM selected some 5,000 workers for a return to offices. The optics remained ugly.
Then the pandemic in 2020 led some 350,000 IBM employees to work remotely around the world. Many already had the necessary technical infrastructure and work culture to do so. But by late spring it began to appear that perhaps some could come back to work, so the previous initiative of consolidating work renewed, while at the same time the firm continued its decade-long process of laying off employees, now many who worked remotely. The objections from employees and recently laid off employees proved intense since at least 2018, so a familiar refrain. One programmer commented, “Yep, IBM’s ‘Back to the Labs’ mandate convinced me to retire in 2018. So their ‘real’ program worked in my case.” Another in 2020 opined that, “this struck me as a disguised layoff targeting people in their 40s and 50s. Also hit people in their 30s.” Another framed the issue differently: “Let’s be honest. IBM had too much real estate it could not sell so it forced employees back to the office and lost thousands of outstanding professionals.” Others defended remote work: “I worked from home for IBM my last 18 years. My productivity was through the roof. They forced us back into open area office space my last 2 years,” and as a result, “tanked moral and IBM has lost a lot of good people.”
While employee suspicions were probably more true than not, also that there was growing evidence that people working in proximity to each other did improve creativity—important as innovation in AI and other forms of IT were needed—IBM’s senior management had lost too much credibility for the press and so many employees opining on websites. These decisions to consolidate back to offices were made largely during the tenure of CEO Virginia Rometty.
IBM was not alone in its long journey through remote work. Just as companies took notice in 2017 and again in 2020 when IBM reversed its remote working models, other companies and government agencies tried to learn more. But some also had a history of working remotely. Office and “high tech” staffs explored possibilities of remote work, largely beginning in the 1970s. One voice that solidified much of the early thinking around why and how to do this was Jack Nilles, known widely as the “father of telecommuting,” who spent the bulk of his career as an engineer associated with aircraft and rocket projects and the 1970s as Director for Interdisciplinary Research at the University of Southern California. Since the 1980s he consulted about telecommuting, authoring books and articles along the way. His publications explained the concept and how to implement it. He helped spread the word among large American corporations about the benefits of remote work, often referencing other initiatives, including IBM’s.
When IBM announced again in June, 2020—as the pandemic was spreading faster than in the previous two months—that it was retreating from remote work, press coverage was of surprise, just as other companies were debating whether to extend remote work beyond Covid-19. Employees and recently retired IBMers complained again, while press coverage expressed puzzlement. IBM felt compelled to trot out its chief medical officer, Dr. Lydia Campbell, to explain. CNN quoted her, “I think we realize at IBM and what most large employers realize is that this pandemic is going to make us all think about new ways of working and different approaches to work.” (Vassel, 2020). By the end of the summer IT workers all over the world were complaining, often refusing to work at any company campus. Management in such firms had no choice but to let their employees work remotely.
Other companies were moving ahead, experimenting, as it was a new way of working for them. The Society for Human Resource Management announced that two-thirds of American companies were working remotely for the first time. CNN reported that Silicon Valley was notorious for resisting attempts to allow their employees to work remotely, and so had little experience, certainly not to the extent as IBM. One compelling reason for the change that struck Silicon Valley workers had dawned on IBMers as early as the 1990s: “It makes no sense paying Bay Area rent if we can earn our salary living elsewhere.” Members of the IT industry were moving in that direction, despite IBM’s opposite march. That they were not following IBM’s lead was an exception to decades of seeing Big Blue as innovative and progressive.
Historians can draw several lessons from this story. The history of mobile working is fraught with complexity in implementation, impact on work productivity, employee morale, role of technology, and company culture. Each of these categories of consequences had varied supporters and critics. Noble and sinister motivates were apparent and hidden. How management worked changed, while the career and political power of employees did too in myriad ways. It is a history that we know very little about, but that goes to the heart of how organizations functioned in the last third of the twentieth century and will probably for years to come. It warrants the attention of sociologists, business management, and historians.
Cortada, James W. (2019). IBM: The Rise and Fall and Reinvention of a Global Icon, MIT Press.
Global Workforce Analytics. (2020). Latest Work-At-Home/Telecommuting/Mobile Work/Remote Work Statistics.
Messenger, Jon C. (2019). Telework in the 21st Century: An Evolutionary Perspective, Edward Elgar.
Meyers, Glenn E. (1999) IBM Field Engineering Experiences: A Personal Memoir, IEEE Annals of the History of Computing, 21. No. 4, 72-76.
Mullen, Regina. (June 2, 2017). IBM Shutters Remote Work: Should You Too?, Replicon blog.
Nilles, Jack M. (1994). Making Telecommuting Happen: A Guide for Telemanagers and Telecommuters, Van Nostrand Reinhold.
__________ (1998). Managing Telework: Strategies for Managing the Virtual Workforce, Wiley.
__________ (2007). The Telecommunications-Transportation Tradeoff: Options for Tomorrow, BookSurge.
Pardes, Arielle. (May 15, 2020). Silicon Valley Rethinks the (Home) Office, Business.
Sak, John C. (2018). The Computer Guy Is Here!: Mainframe Mechanic, Self Published.
Streitfeld, David. (June 29, 2020). “The Long, Unhappy History of Working From Home,” New York Times.
Useem, Jerry. (November 2017). When Working From Home Doesn’t Work: IBMPioneered Telecommuting. Now It Wants People Back in the Office, The Atlantic.
Vassel, Kathryn. (June 25, 2020). IBM’s Chief Medical Officer: We Won’t Rush to Bring People Back, CNN.
[Note: Quoted material from the author's recent survey of IBMers on Facebook.]
James W. Cortada, (August 2020) “From Telecommuting to Mobile Work: The IBM Experience, 1890s-2020.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1, Charles Babbage Institute, University of Minnesota, 23-34.
About the author: James W. Cortada is a Senior Research Fellow at the Charles Babbage Institute, University of Minnesota—Twin Cities. He conducts research on the history of information and computing in business. He is the author of IBM: The Rise and Fall and Reinvention of a Global Icon (MIT Press, 2019). He is currently conducting research on the role of information ecosystems and infrastructures.
Margaret Dykens, MLIS, MS, Curator and Director of the Research Library San Diego Natural History Museum
With preface by Amanda Wick, Interim Archivist, Charles Babbage Institute Archives
Who was Charles Babbage?
Charles Babbage, Victorian scientist and mathematician, was born on December 26, 1791 to a family of London bankers. Fascinated with mathematics, and especially algebra, he studied the subject at Trinity College, Cambridge. While attending Cambridge, he co-founded the Analytical Society for promoting continental mathematics and reforming traditional teaching methodologies of the time. Many of these methods are still used in some form today in the instruction of algebra.
Following completion of his degree, Babbage worked as a mathematician for the insurance industry. He was elected a Fellow of the Royal Society in 1816 and played a prominent part in the foundation of the Astronomical Society (later Royal Astronomical Society) in 1820. As a member of the Royal Society during the heady days of the early 1800s, Babbage came into contact with a number of great thinkers and engaged in a robust correspondence with fellow mathematicians, naturalists, and philosophers—including Sir William Herschel, Charles Darwin, and Ada Lovelace.
In 1821 Babbage invented the first of his two calculating machines, The Difference Engine, which would quickly become his singular passion and focus. The function of the Difference Engine was intended to compile mathematical tables and, on completing it in 1832, he began work on a more complex and multifunctional machine that could perform any kind of calculation. This was the Analytical Engine (1856) and its invention is widely considered to be the founding of the field of modern computing.
Today, little remains of Babbage's prototype computing machines and, unfortunately, critical tolerances required by his machines exceeded the level of technology available at the time. Though Babbage’s work was formally recognized by respected scientific institutions, the British government suspended funding for his Difference Engine in 1832, and after an agonizing waiting period, ended the project in 1842. Though Babbage's work was continued by his son, Henry Prevost Babbage, after his death in 1871, the Analytical Engine was never successfully completed, and ran only a few "programs" with embarrassingly obvious errors.
Despite his many achievements in mathematics, scientific philosophy, and his leadership in contemporary social movements, Babbage’s failure to construct his calculating machines left him a disappointed and embittered man. He died at his home in London on October 18, 1871.
What’s in a name?
The calculating engines of English mathematician Charles Babbage (1791-1871) are among the most celebrated icons in the prehistory of computing. Babbage’s Difference Engine No. 1 was the first successful automatic calculator and remains one of the finest examples of precision engineering of the time. Babbage is sometimes referred to as "father of computing." The International Charles Babbage Society (later the Charles Babbage Institute) took his name to honor his intellectual contributions and their relation to modern computers.
Where is Babbage in the Archives?
Materials related to Charles Babbage are scattered around the world, with the vast majority of his personal papers and library held at the Science Museum of London and the British National Library. Although the Charles Babbage Institute is named after Charles Babbage, we actually have very little material originating with our namesake. What we do have are first editions of many of his books and journal articles and a number of these are inscribed with dedications to his patrons by the author. These rare materials constitute the earliest materials in our repository and, while used in classroom settings and on exhibit, rarely leave our vault. Our holdings of Babbage’s work include the following:
- Babbage, Charles. On a Method of Expressing by Signs the Action of Machinery. London: [Royal Society of London], 1826.
- Babbage, Charles. Reflections on the Decline of Science in England, and on Some of Its Causes. London: Printed for B. Fellowes (Ludgate Street); and J. Booth (Duke Street, Portland Place), 1830.
- Babbage, Flather, Dodgson, Flather, John Joseph, and Dodgson, Charles. On the Economy of Machinery and Manufactures. London: C. Knight, 1832.
- Babbage, Charles. Passages from the Life of a Philosopher. London: Longman, Green, Longman, Roberts, & Green, 1864.
- Babbage, Charles. The Ninth Bridgewater Treatise: A Fragment. Second Edition., Reprinted. ed. Cass Library of Science Classics; No. 6. London: Cass, 1967.
What is the Ninth Bridgewater Treatise?
One of the titles in Babbage’s oeuvre that is uniquely significant is the Ninth Treatise of Bridgewater. This volume presents Babbage’s perspective on the Eight Treatises of Bridgewater—a series of work by multiple influential thinkers of the Victorian era on natural history, philosophy, and theology. Babbage’s contribution is not officially affiliated with the eight-volume series and was merely his own considerations on the topic. In his volume, which he titled the Ninth Bridgewater Treatise, he discusses his calculating machines and posits the idea of God as a divine programmer who established the rigid natural laws which govern humanity and civilization, in many it presents a case for Deux et Machina.
As a fragmentary piece, and one that does not dwell on mathematical or scientific subjects, this is rarity amongst Babbage materials. Our copy is a second edition and, while in excellent condition, it is not especially rare. Recently, the Curator and Director of the Research Center at the San Diego Natural History Museum, Margaret Dykens, experienced one of those once-in-a-lifetime finds when she reviewed an anomaly within their catalog, an edition of Babbage’s Ninth Treatise of Bridgewater that seemed to be a galley proof. As she notes in the following article, deep examination of the item by both herself and noted Babbage scholar, Dr. Doron Swade, made several incredible finds.
Charles Babbage Institute. (10 June 2020). “About Charles Babbage.” Charles Babbage Institute web site. http://www.cbi.umn.edu/about/babbage.html.
Swade, Doron. (12 June 2020). "Babbage, Charles (1791–1871), mathematician and computer pioneer." Oxford Dictionary of National Biography. 23 September 2004. https://www.oxforddnb.com/view/10.1093/ref:odnb/9780198614128.001.0001/odnb-9780198614128-e-962.
Amanda Wick (July 2020). “Charles Babbage’s Ninth Bridgewater Treatise.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1, Charles Babbage Institute, University of Minnesota, 17-22.
About the author: Amanda Wick is the interim archivist at the Charles Babbage Institute Archives (CBIA) at the University of Minnesota. Prior to working at CBIA, Amanda led major processing projects at the University of Minnesota and managed the archives of the Theatre Historical Society. She obtained her Bachelor’s degree in Environmental Studies from Lawrence University (Appleton, WI) and her Masters in Library and Information Science from Dominican University (River Forest, IL).
Charles Babbage’s Ninth Bridgewater Treatise in the SDNHM Library
Margaret Dykens, MLIS, MS, Curator and Director of the Research Library San Diego Natural History Museum
Abstract: As a foundational figure in the history of science, Charles Babbage is best known for his contributions to computing. In fact, his mechanical, programmable calculating machines are considered precursors to modern computers. These accomplishments were the primary reason for the naming of the Charles Babbage Institute, and its archivists have sought to honor its namesake through the purchase of rare books authored and inscribed by him. One such book is a fragmentary oddity, the Ninth Bridgewater Treatise, and a copy owned by the San Diego Natural History Museum that was recently examined by curatorial staff and prominent Babbage scholar, Dr. Doron Swade, holds curious clues to Babbage's approach to natural philosophy. (KW: Babbage, Charles; Swade, Doron; computing history; rare books; antiquities; archives.)
The Research Library of the San Diego Natural History Museum (SDNHM), founded in 1874, has extensive holdings of rare and antiquarian books, including natural history volumes dating back to 1514. The majority of these books were donated by various naturalists and philanthropists over the past one hundred years. One such naturalist was General Anthony Wayne Vogdes (1843-1923), a career Army officer with an active secondary career as a geologist and paleontologist. Vogdes was also an avid bibliophile and donated his extensive scientific library to the SDNHM after his death in 1923. One of the books from Vogdes’ library was a first edition of Charles Babbage’s Ninth Bridgewater Treatise (1837).
This particular volume was mentioned in a newspaper article published on January 11, 1896 in the San Francisco Bulletin, which described many of the most important books in Vogdes’ personal library. Babbage’s Ninth Bridgewater Treatise is mentioned in the list with the comment that it contained “annotations by the author.” The book in question appears to be a galley proof with wide margins and many hand-written pencil annotations, as well as marginalia likely written by the author.
There is also a portion of a hand-written letter bound into the book itself—Vogdes was an amateur book-binder and his library consists almost exclusively of his own bindings, many of which have notes, letters, images, or other memorabilia that he collected and bound into the text.
I was intrigued by the hand-written annotations and marginalia in Vogdes’ copy of the Ninth Bridgewater Treatise and contacted Dr. Doron Swade, preeminent Babbage scholar and retired curator of the Charles Babbage collection at the Science Museum of London, for verification of the handwriting. After emailing Dr. Swade several images of the annotations, he replied to me that it was highly likely that they were in Charles Babbage’s own hand, both because of the style of writing as well as the content itself. To quote Dr. Swade:
Having gone through the 7,000 manuscript sheet (ms) of Babbage Scribbling Books the handwriting in what is visible on the folded manuscripts interleaved on page 128, and in the third image, looks very much like Babbage’s, as do the pencilled annotations.
But there is stronger evidence for the annotations and ms being his: in the preface ‘advertisement’ to the second edition Babbage states that the chapter ‘On Hume’s Argument Against Miracles’ has been ‘nearly rewritten’. The first image you sent with the pencilled annotations, which are surely from the first edition, correspond to changes made in the second edition. It is not credible that anyone other than Babbage would have made what are essentially editorial instructions, and editorial amendments, that were carried through to the second edition.
There is even more conclusive evidence in the sample page 131 where the pencilled annotations appear verbatim in the second edition, and the several pencilled deletions have also been carried through.
The ms in the third of the images you sent starts with the same opening sentence that appears in the second edition at the top of page 127 though what follows has been edited and amended. It could be that this is a sheet from the original manuscript for the first edition though not having access to a first edition I am unable to confirm this.
It is fair to conclude that the annotations are Babbage’s. It is difficult to see any other explanation.
Although I do not know how General Vogdes came to have this particular annotated first edition of the Ninth Bridgewater Treatise in his collection, I am not surprised as his entire library constituted over seven thousand scientific volumes on topics related to geology, paleontology, and other scientific and philosophical disciplines. Indeed, his personal library included works by Darwin, Hume, Dana, Agassiz, and Lyell as well as many other well-known natural historians and intellectuals.
We are hopeful that this unique source might be of interest to some Babbage researcher or historian. Any scholars interested in pursuing this topic further should feel free to contact me directly at the SDNHM Research Library.
Swade, Doron, Dr. “’Ninth Bridgewater Treatise.’ Message requesting assistance in authenticating possible rare volume by Charles Babbage.” Message to Margaret N. Dykens. January 2020. E-mail.
Margaret N. Dykens (July 2020). “Charles Babbage’s Ninth Bridgewater Treatise in the SDNHM Library.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1, Charles Babbage Institute, University of Minnesota, 17-22.
About the author: Margaret N. Dykens received her Master’s degree in Biology from the College of William and Mary, Williamsburg, Virginia in 1980. Upon graduation, she was hired as Staff Illustrator at the Harvard University Herbarium. Margaret went on to earn a second graduate degree in Library Science from the University of Michigan School of Information in 1993. In 1997, she became the Director of the Research Library for the San Diego Natural History Museum (SDNHM). In addition to her work directing SDNHM, she has served as curator for two exhibitions; the first was The California Legacy of A.R. Valentien, based on the Museum’s fine art collection, where she toured with this exhibition to numerous venues across the U.S. In 2016, she also curated the permanent exhibition, Extraordinary Ideas from Ordinary People: A History of Citizen Science, based on fine art works, historical objects, and rare books from the Research Library.
Alejandro Ramirez, PhD, Sprott School of Business – Carleton University
Abstract: A series of wrong decisions precipitated the Y2K crisis: adopting the 6-digit date format, using COBOL as the standard in business computing and discontinuing COBOL-teaching in many American universities shortly after it was adopted. Did we learn anything from this crisis? (KW: Y2K crisis, COBOL, Internet history, Outsourcing.)
Twenty years ago, we averted the Y2K crisis. When we talk about the crisis, people are genuinely puzzled that it was a very expensive affair. They have a distorted idea about a crisis that did not happen, or how it was supposed to be the end of the world, but at the end, nothing actually happened. Then they wonder if something similar could happen again. That is really the crux of the matter: what did we learn from the Y2K crisis?
Knowing the history of this crisis is an important and serious endeavour. It is a benefit to understand how computer usage evolved, and what forces shaped our technology, our practices, and computers’ contribution to society. History becomes an indispensable light guiding us in this understanding.
What were they thinking?
Employment of personnel to use computers in businesses became widespread in North America with the introduction of the IBM 1401 in 1959. Before, if any, machine-based data processing generally was executed by electromechanical accounting machines. Calendar days, if needed, were fed via punched cards, indicating the date appropriate for that job. When programmers from the late 1950s to the mid-1960s decided that in order to save on memory costs (McCallum 2019), they will use only the last two digits of the year, i.e., 60 instead of 1960, they never imaging that their programs will still be running at the end of the 20th Century. After all, 40 years seemed a very long time, especially since they were saving approximately $16.00 USD per date by saving two bytes, 16 bits, of core memory valued at about one dollar per bit.
When IBM announced their new, more powerful System/360, with many innovative features compared to their 1400s technology, they also decided—in the interest of compatibility—that their system’s date would also be a 6-digit date. To cement this practice, on November 1, 1968, the U.S. Department of Commerce, National Bureau of Standards, issued a Federal Information Processing Standard which specified the use of 6-digit dates for all information exchange among federal agencies (FIPS 1968). The standard became effective in January 1, 1970, enshrining the 6-digit date standard by the bureaucracy of government, also with little to no thought of the year 2000.
It took about fifteen years for someone to realize that having a 6-digit date may be a problem. Unknown to most but a few programmers, Jerome and Marylin Murray published their call to arms Computers in Crisis: How to Advert the Coming Worldwide Computer Systems Collapse in 1984. They credited their daughter Rosanne, a senior research analyst at Systemhouse, Ltd., of Ottawa for the origins of the book: “This book may not have been undertaken were it not for a lengthy telephone discussion of the dating problem with Rosanne…Her interest and encouragement have been unflagging” (Murray & Murray 1984, p. xix).
Shortly after the book was published, Spencer Bolles posted on January 18, 1985, from his computer in Reed College in Oregon, the first recorded mention of the Year 2000 problem on a Usenet group: “I have a friend that raised an interesting question that I immediately tried to prove wrong. He is a programmer and has this notion that when we reach the year 2000, computers will not accept the new date” (Bolles 1985).
In March 1959 Burroughs Corporation computer scientist Mary Hawes called for an industry and government consortium in order to develop a standard programming language for business—promoting greater portability for organizational users transitioning mainframe computers. With appearances of Autocode, FLOW-MATIC, FORTRAN, ALGOL-58, and other 1950s programming languages, she recognized the high costs of proliferation.
Feeding the Beast
From the 1960s into the 1990s, many universities offered COBOL courses, as did companies and vocational schools like Control Data Institutes. Today, in an age where AI/analytics, games, robotics, cloud, and the internet of things are foremost for many computer science students, few consider learning legacy systems and legacy languages. Accordingly, COBOL courses are scarce. A Slate article quoted Prof. John Zeanchock, Robert Morris University, stating just 37 colleges and universities globally have a “mainframe course” on the curriculum. Most schools’ faculty are unable to suggest legacy specialist students/graduates when banks or local governments call. (Botella 2020). In our culture, Innovation is revered, and maintenance is not. In IT there is a myopic attention to the latest tech and a failure to recognize and value that IT maintenance requires great skill and can be innovative (new processes, new fixes, etc.). Privileging innovation over maintenance is also in part tied to gender stereotypes and discrimination as historically women have had greater opportunity in the critical areas of services, maintenance (both machines and debugging), and programming (from plug board to languages), and fewer opportunities in computer and software engineering (Yost, 2011, 2017).
The percentage of women majors in computer science declined sharply the past quarter century—from more than 35 percent in the 1980s to 18.1 percent in 2014, only varying slightly since (nsf.gov/statistics). The reasons are varied, but gender stereotyping, a male dominant computing culture, and educational and workplace discrimination are factors (Abbate, 2012; Hicks, 2017; Misa, 2011). This has furthered labor shortages (all areas, including legacy) and held back computer science. Labor shortages can become all the more profound in times of crisis, including the current health and economic crisis.
More than a Jersey Thing
On April 6, 2020, New Jersey Governor Phil Murphy made a public plea for volunteer “Cobalt” programmers (meaning COBOL) to aid New Jersey and help with glitches to an overburdened unemployment benefits computer system more than 40 years old. New Jersey was having difficulties with timely processing of unemployment payments to the flood of new filers. The increased burden (volume and parameters) on the unemployment system was a major bottleneck, or to borrow Thomas Hughes’ term, reverse salient, to timely and accurate data processing to respond to those in need (Hughes, 1983).
This sparked an onslaught of journalist articles as well many Twitter, Facebook and other social media posts. The critiques ranged from Governor Murphy/New Jersey having an antiquated unemployment insurance computer system to calling for volunteers from a population segment that would undoubtedly be the most susceptible to COVID-19 risk—the elderly. Meanwhile, social media erupted with jokes with ageist images of elderly individuals as potential volunteers.
Other states, including Connecticut and Kansas, had similar shortages of trained COBOL experts to confront unemployment insurance system challenges. Understandably, unemployed workers waiting for unemployment benefits are extremely frustrated and angry, expressing as much on the Kansas Department of Labor (KDoL) platform. Much is the matter with Kansas’ system, with its origins in the 1970s, and inadequate updates for flexibility and scale. In late April, KDoL indicated a timeline where processing could occur by late May (for many that will push the wait to months). For states that have prioritized investing in updating other computer systems, but not unemployment insurance, it amounts to neglecting infrastructure that serves the most vulnerable in society.
Why do so many states have ill-equipped IT systems for unemployment benefits processing? Replacing long existing systems is complex and expensive (hundreds of millions of dollars). Change is also disruptive to existing labor, existing skill sets. Unemployment systems serve those lacking political power; federal and state governments deprioritize them. Further, systems (in all their technical, political, economic, and other contexts) become entrenched, or to use Hughes’ concept, gain momentum (Hughes, 1983). Failures/pressures can redirect momentum, some states scrambled for cloud solutions once systems crashed in April—possibly the least bad option, but also suboptimal timing, new systems and processes on the fly are especially difficult. Regardless, the problem is one of infrastructure—not valuing maintenance, labor, and recipients. It is not merely COBOL versus the cloud, in fact, COBOL can and does integrate with AWS, Azure, and IBM clouds, hybrid cloud is common.
State IT Workers and Hired Guns’ Heroic Efforts
North Texas’ COBOL Cowboys staffing firm, larger IT services enterprises, and COBOL-skilled independent contractors are in great demand. The governors, state DoLs, and state CIOs are doing their best to staff up to address problems. For the systems analysts, programmers, and other state employees and contractors the hours are long, work difficult, and efforts truly heroic. The Federal CARES Act’s unemployment benefits, PUA/PECU, allows states to extend the duration of benefits, and include those usually not eligible—the self-employed. This adds greatly to both volume and complexity. In my playful title, “play” is used for where work plays/is performed (fewer coders choosing legacy) and to highlight coders’ creativity—in the spirit of CS metaphors like “sandbox” for building (non-live) code.
Domestic and Global Digital Divides
In the coming year, the overall percentage of Americans below the poverty line will peak higher than any time in more than 50 years— the impact for African-American, Hispanic, and Native-American populations is particularly severe. The disparity of access to health insurance, banking, loans, and information technology, as well as exposure to risk, and disparity of incidence and mortality with COVID-19, highlights extreme and growing race and class inequality in the United States.
Washington D.C.’s unemployment platform urges benefits filers to use Microsoft Explorer. Microsoft retired Explorer in January 2016, an unsupported version remains for computers, not smart phones. A Pew Research Center 2019 survey showed 54 percent of Americans under $30,000/year income have a computer, while 71 percent have a smart phone. For those making over $100,000, 94 percent have a computer/broadband at home. (Anderson and Kumar, 2019). Only 58 percent of African-Americans have a computer, versus 82 percent for whites. (Perrin and Turner, 2019) In digital, just like education, healthcare, housing, and other infrastructure, there are two Americas.
Y2K: Why to Care
An earlier crisis largely involving COBOL, one with a long and visible runway, is both consequential context and instructive to current challenges. About a quarter century ago, governments and corporations began seriously addressing the pending Y2K crisis—caused by two digits for date often in COBOL code—to avert risks to life and the economy, to make it a nonevent.
Investments and global cooperation were key and the International Y2K Cooperation Center played a meaningful role in fostering collaboration. The shortage of programmers knowledgeable in COBOL, and the lower expense and overwhelming volume of code, led to outsourcing to an emerging Indian IT services industry. This lent momentum to this trade, and to a shifting geography in IT work that remains impactful (though corporate decision-makers are accelerating artificial intelligence applications producing further labor transformations, ones detrimental to Indian IT laborers, developments standout ABD sociologist and CBI IDF Fellow Devika Narayan is insightfully analyzing). Gartner Inc. estimated U.S. government and business expenditures were up to $225 billion, a breathtaking sum indicative of costs of putting off maintenance until a time-sensitive crisis. In passing into the new millennium with few major problems, the situation lent credence to two diverging interpretations—that heavy investment in maintenance had been necessary to avert catastrophe, or more common (and less accurate), that it was an overhyped problem leading to squandered funds in preparing, in maintenances fixes. Offshoring saved money in the short run, but may not have in the longer run, it left a legacy of less and less current, on-shore COBOL expertise (for maintenance, updates, security, etc.), a workforce and talent helpful in global crises, particularly ones in which unfortunate (U.S.) nationalistic tendencies and policies have inhibited international cooperation.
CONNECT and Disconnects
Maintaining infrastructure is important. Anemic IT budgets have not only hurt opportunities to change and move to innovative new solutions, but also to best maintain existing systems and to better assure their ability to perform and to perform to scale in both normal times and crises. The reverse salient certainly is not always COBOL or COBOL alone. State auditors warned Florida Governor Ron DeSantis that Florida’s unemployment site, its “CONNECT” cyberinfrastructure, had more than 600 systems errors in need of fixing, but that state officials had “no process to evaluate and fix.” (Mower, 2020). It was a 2013 $77 million system, which he is quick to point out, his administration inherited. This underlines the challenge not just in Florida but many States—inadequate infrastructure is the predecessors’ fault, is not the current leaders’ problem, and fixes should lie with successors. Often the (now) multi-hundred million-dollar cost typical of major upgrades to new unemployment insurance systems (and ongoing refinement) is difficult without federal assistance. Florida’s CONNECT is a reminder of damaging disconnects, and leaders’ inattention to infrastructure for vulnerable people. The problem is also one of meager and dwindling federal support. Federal aid for state unemployment administration has been dropping for a quarter century with severe cuts in 2018 and 2019. In a survey (pre-COVID-19) more than half of the states responded their unemployment system problems were “serious” or “critical.” (Botella 2020).
Neglected Infrastructure and Crashes
Working two tenths of a mile from the site of the 2007 Interstate 35 West Mississippi River Bridge collapse in Minneapolis, is a frequent reminder that strong, safe, and well-maintained infrastructure is essential. Twenty-eight percent of infrastructure project funding at the state level comes from federal grants (primarily for physical infrastructure). States’ invisible software infrastructure is starved, especially unemployment systems. Hopefully the COVID-19 pandemic leads not only to evaluating our medical preparedness with ICUs, PPE, and unmet needs in free enterprise insurance and healthcare, but also greater evaluation of IT infrastructures. Ideally, the developments will lead all governors with poor unemployment insurance system performance to the same conclusion as Governor Murphy about the need for post-mortems on digital infrastructure. As he put it “how the heck did we get here when we literally needed COBOL programmers”— learning from the past is important.
One thing clear from the two COBOL crises is that history and archives matter—my thoughts here have at best just scratched the surface on fundamental IT infrastructure and contexts someone could analyze with tremendous depth using Charles Babbage Institute resources. CBI’s archival and oral history resources (most transcripts online, all free) to study the Y2K crisis and the history of CODASYL and COBOL (and many other topics and themes in the history and social study of computing) are the finest and most extensive in the world. A talented University of Pennsylvania doctoral candidate in the History and Sociology of Science, Zachary Loeb, has drawn on CBI’s International Y2K International Cooperation Center Records for his important dissertation on the cultural, political, and technical history of Y2K.
Over the years, a number of researchers have used our Conference on Data Systems Languages (CODASYL) Records. While it stands out on documenting COBOL and the group’s work with databases (what occurred in 1959 and far beyond), we have many other COBOL materials in a variety of collections. One such collection (a recent one) is our largest overall collection at more than 500 linear feet, the Jean Sammet Papers—Sammet may have been the single most important developer with COBOL. Likewise, our Frances E. (“Betty”) Holberton Papers has rich material on CODASYL and COBOL. There is also great COBOL content in our Burroughs Corporate Records, Control Data Corporation Records, Gartner Group Records, Auerbach and Associates Market and Product Reports, IBM SHARE, Inc., HOPL 1978, Charles Phillips Papers, Jerome Garfunkel Papers, Warren G. Simmons Papers, National Bureau of Standards Computer Literature, Computer Manuals, and many other collections. COBOL’s history is one of government, industry, and intermediaries’ partnerships, standards, maintenance, labor, gender, politics, culture and much more. In a technical area that always seems focused on the new, new thing, its 60-year past and its continuing presence deserve greater study.
Abbate, Janet. (2012). Recoding Gender: Women’s Changing Participation in Computing, MIT.
Allyn, Bobby. (2020). “COBOL Cowboys Aim to Rescue the Sluggish State Unemployment Systems." NPR, April 22, 2020.
Anderson, Monica and Madhumitha Kumar. (2020). “Digital Divide Persists…” Pew Research Center, May 7, 2020.
Botella, Ella. (2020). “Why New Jersey’s Unemployment System Uses a 60-Year-Old Programming Language.” Slate, April 9, 2020.
Charles Babbage Institute Archives (finding aids to the collections mentioned in final paragraph).
Hicks, Marie. (2017). Programmed Inequality: How Britain Discarded Women Technologists and Lost Its Edge in Computing, MIT Press.
Hughes, Thomas P. (1983). Networks of Power: Electrification in Western Society, 1880 to 1930, Johns Hopkins University Press.
Kennelly, Denis. (2019) “Three Reasons Companies are only 20% Into Cloud Transformation.” IBM.com, March 5, 2019.
King, Ian. (2020). “An Ancient Computer System is Slowing Giant Stimulus.” Bloomberg.com, April 13, 2020.
Mazmanian, Adam. (2014). “DoD Plans Upgrade to COBOL-based Contract System” FCW, July 7, 2014.
Misa, Thomas J., ed. (2011). Gender Codes: Why Women are Leaving Computing, Wiley.
Mower, Lawrence. (2020). “Ron DeSantis…” Tampa Bay Times, March 31, 2020.
Perrin, Andrew and Erika Turner. (2019) “Smartphones Help Blacks and Hispanics Bridge Some—But Not All—Digital Gaps with Whites,” Pew Research Center, August 20, 2019.
Yost, Jeffrey R. (2011). “Programming Enterprise: Women Entrepreneurs in Software and Computer Services,” in Misa, ed. [full cite above].
Yost, Jeffrey R. (2017). Making IT Work: A History of the Computer Services Industry, MIT Press.
Special thanks to CBI Acting Archivist Amanda Wick for discussion/insights on COBOL and our collections.
Jeffrey R. Yost (May 2020). “Where Dinosaurs Roam and Programmers Play: Reflections on Infrastructure, Maintenance, and Inequality.” Interfaces: Essays and Reviews on Computing and Culture Vol. 1, Charles Babbage Institute, University of Minnesota, 1 - 8.
About the author: Jeffrey R. Yost is CBI Director and HSTM Research Professor at the University of Minnesota. He has published six books (and dozens of articles), most recently Making IT Work: A History of the Computer Services Industry (MIT Press, 2017) and FastLane: Managing Science in the Internet World (Johns Hopkins U. Press, 2016) [co-authored with Thomas J. Misa]. He is a past EIC of IEEE Annals of the History of Computing, and current Series Co-Editor [with Gerard Alberts] of Springer’s History of Computing Book Series. He has been a principal investigator of a half dozen federally sponsored projects (NSF and DOE) on computing/software history totaling more than $2 million. He is Co-Editor [with Amanda Wick] of Interfaces: Essays and Reviews in Computing & Culture.