Essays and Reviews in Computing and Culture 

Kids at Computer

Interfaces publishes short essay articles and review essays 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. 

Editors: Jeffrey R. Yost and Amanda Wick



Charles Babbage’s Ninth Bridgewater Treatise

Margaret Dykens, MLIS, MS, Curator and Director of the Research Library San Diego Natural History Museum

Preface by Amanda Wick, MLIS, Interim Archivist, Charles Babbage Institute Archives

(PDF version available for download.)


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.

Swade, Doron. (12 June 2020). "Babbage, Charles (1791–1871), mathematician and computer pioneer." Oxford Dictionary of National Biography. 23 September 2004.

Amanda Wick, “Charles Babbage’s Ninth Bridgewater Treatise.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1 (Charles Babbage Institute, University of Minnesota, July 2020): 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.)

Charles Babbage ninth treatise


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.

Charles Babbage treatise 2


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.

Charles Babbage treatise 3


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, “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, July 2020): 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.


Back to top


Of Bugs, Languages and Business Models: A History

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

(PDF version available for download.)


Y2K Time magazine
TIME magazine addressing Social misunderstanding (Courtesy of the of Charles Babbage Institute Archives)


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

Millennium bug
Few were able to distinguish facts from fiction (Courtesy of Charles Babbage Institute Archives)

Both, Spencer L. Bolles’ unnamed friend and Rosanne Murray seem to be the ones that started to worry about this issue. They are the ones that people do not know about, and perhaps with them, many others. But the prominence of the problem was best known once David Eddy called it “Y2K” (Rose 1999).  Before Eddy’s acronym, the problem was referred to as Century Date Change (CDC), Faulty Date Logic (FADL), Millennium Bug. For Eddy, “Y2K just came off my fingertips” explains Rose (1999).

Reading Murray and Murray (1984), it becomes apparent that regarding the state of computer resources in business not much has changed. The following paragraph can be found in today’s stories regarding the use of computers in organizations: “All this explodes in the midst of a world economy totally dependent upon computer resources for its survival and demanding of the services of skilled technical personnel whose availability is in dreadfully short supply” (Murray & Murray 1984, p. 221). In 1984 the comment was more about the skills needed to debug all those programs used by organizations using 6-digit dates. No one knew exactly how many programs needed fixing. The task was clear: “Our fault is in our readiness to ‘patch’ or treat symptoms until it is often too late to successfully eradicate the disease” (Murray & Murray 1984, p. 334). Its magnitude was not.

Cost-savings in core memory and using a 6-digit date standard imposed by government are pieces of evidence in the story of why the Y2K Bug was so problematic. To completely understand its ramifications, it is necessary to briefly talk about how Common Business Oriented Language (COBOL) became the Lingua Franca of business programming.

In answering the question many of us have asked regarding what programmers were thinking when they created their programs, it is important to remember that one works within the reality we create and within the space of actions allowed in a given domain (Heidegger 1993). Programmers must comply with current standards when writing their code. The 6-digit date was one of them.

Washington, we have a problem

At the beginning of the second half of the twentieth century, the computer started to move away from being only for science and engineering as more large corporations and government organizations adopted computers to become “the most vital tool of management introduced in this decade” (Lohr 2001, p. 44). It was entering into accounting, payroll, logistics, manufacturing and purchasing. But at that time programs were still a foreign language to managers and the need to use a language to solve management and business problems became essential.

As its name indicates, COBOL was a Common Business Oriented Language. It had everything to be rejected: it was a language designed by a committee, it was not intellectual enough to entice computer scientists to be interested in it, it was created for practical reasons and agreed upon computer vendors. Could there be a common language to have the business community working together? That was the premise in April 1959 for a meeting at the University of Pennsylvania computer centre.

The same year, in late May, the Pentagon hosted a 2-day meeting attended by most of the computer makers and some heavy computer users in businesses, a group of about 40 people. From this, and subsequent meetings, a ‘short-term’ committee of six was formed. Some names for this language were discussed, among them: Busy (Business System), Infosyl (Information System Language), Datasyl (Data System Language), and Cocosyl (Common Computer Systems Language). According to Grace Hopper, it was Robert Bremer who proposed the name Common Business Oriented Language (COBOL). The committee delivered “the business FORTRAN,” it was now up to vendors to adopt it and have their machines ready to be delivered to organizations COBOL-ready.

COBOL report
COBOL the language of Business applications (Public Domain)

Computer vendors worldwide decided to use COBOL as the language for their business clients. And without questioning, businesses worldwide started to use COBOL as the language for developing any business solution. The language was simple enough that programmers were able to learn it quickly and join in the effort and suddenly, the business world was running on COBOL.

It is important to note that computer scientists were not particularly interested in a language created by a committee, but they saw the need to teach it in the curriculum for a few years, until more interesting academic languages were designed and attracted their attention: C, Algol, Pascal, C++. Slowly, COBOL courses started to dwindle in many universities, to a point that by the mid-1980s, there were not many computer science students who knew how to program in COBOL. It was clear that COBOL was the business FORTRAN, a huge achievement, especially in a field where users care more about their discipline (business) than about computers. It became clear that computers were useful tools, but tools, nonetheless.

The Achilles’ heel of COBOL was not its syntax but, its heavy reliance on the highly adopted 6-digit date standard to manipulate time-based business data. Once it became evident that many COBOL programs were vulnerable to the Y2K bug, the call for action became louder. In Murray and Murray’s own words: “This is a true computer crisis—it is application and nationality independent. It is worldwide. It has but one certain remedy—immediate action to terminate 6-digit date involvement in current system development and the scheduling of the ultimate conversion of existing systems” (Murray & Murray 1984, p. 334).

But, could this call to arms be enough to mobilize companies all over the world to find a way to solve the problem? For that, it was needed to estimate its costs. The bottom line was simple: what is more expensive, the problem or its cure?

As an example, Lyons (1981) talks about one Fortune 500 company, based in Chicago, that had a library of 50,000 COBOL programs. Each program with an average of 750 lines, giving an estimated 37,500,000 lines of code in that library. Having a hypothetical programmer able to debug 100 lines of code per day, that will leave him with 42.8 years working every single day, seven days a week. To finish the job in one year, you need to find another 42 equally efficient programmers and coordinate them to do the job! This, for one library, in one company! It was immediately clear that the job was momentous.

Suddenly the need for COBOL talent was clear, but there were not many new computer science students in the pipeline that knew COBOL. Most COBOL programmers were working in the field performing their daily tasks. They couldn’t be asked to stop working and start debugging. There were few COBOL professors left in a handful of universities that over night received job offers to head and manage COBOL teams tasked with debugging programs. It became impossible for universities to keep that unused talent in house, especially considering the salaries offered to them. Those organizations that did not want to enter the bidding salary wars for COBOL talent and decided to develop their own. Three years before the year 2000, according to a CIO quoted by Callaway (1997), “A good mainframe programmer today is worth his [or her] weight in gold.”

The Y2K bug was a costly undertaking, but it was vital to tackle it. Arranga and Price (2000) using a pop culture metaphor indicate the importance of the Internet, and the emerging World-Wide-Web in solving the Y2K problem: “Perhaps the most important Y2K side effect provided Cobol with something it had always lacked: a broad-based community of developers focused on providing Cobol with options. With too much code to be repaired manually, a market of software remediation tools came of age. The tools did not turn into pumpkins at the stroke of midnight. Instead they kicked off the other shoe, took off the gown, put on a Spidergirl outfit, and swung onto the Web” (p. 18).

Outsourcing image
Outsourcing: Solution or Problem? (This Photo by Unknown Author is licensed under CC BY-NC-ND)

The Internet, Y2K, and Outsourcing to India

Internet adoption all over the world became the norm. India was among the biggest adopters. Thomas Friedman in his 2005 best seller The World is Flat, includes outsourcing as the fifth, among ten ‘flatteners’ of his model explaining how the modern world became flat. In the story Friedman tells about outsourcing, the principal character is none other than the Y2K bug. According to him, suddenly, India became linked to North America through fiber-optic, just at the time that the Y2K bug became an urgent reality at one end of the link, India had a surplus of COBOL programmers at the other. “And so with Y2K bearing down on us, America and India starting dating, and that relationship became a huge flattener, because it demonstrated to so many different businesses that the combination of the PC, the Internet, and fiber-optic cable had created the possibility of a whole new form of collaboration and horizontal value creation: outsourcing” (Friedman 2005, p. 108).

If the Y2K bug was a big problem for the West, it became a big opportunity for India. Suddenly every single computer running COBOL programs in the West needed to be reviewed. The enormous task of checking programs line-by-line required an equally enormous number of qualified people, these people were available in India. This gave Indian IT companies the opportunity to work side by side with the largest Western corporations. Before Y2K, India was producing many IT professionals hoping that they will find a position somewhere in the west. And many did, but thanks to the Y2K bug, suddenly these IT professionals did not need to leave India to work for these corporations.

Outsourcing from America to India, as a new way to collaborate exploded after the year 2000. Remember, soon after the year 2000, the dotcom bust shocked many companies that had emerged around the time of the Y2K. This bust, a problem for many start-up companies in North America, was another opportunity for Indian companies. Since these companies were already linked to the West, the bust made the cost of using these links virtually free.


Shortly after it was clear that the Y2K bug problem had been solved, Kappelman (2000) made an evaluation of what he called “Some Strategic Y2K Blessings.” He starts by listing a series of issues that became evident to the profession while working on solving the problem: “Y2K showed everyone the importance of systems and software in enterprise success…the value of inventorying and tracking IT assets, maintaining standards for software processes including careful version documentation, quality testing practices and independent validation, simplicity in software and systems, clearly defining project management, and a reasonable balance between centralization and decentralization” (p. 42). Somehow, along the way, working on the solution, other issues became more prominent and it seems that the profession forgot about those standards that were imposed in their practice, i.e., using a 6-digit date standard, and using COBOL as a de facto language for business applications. In hindsight adopting those standards was more a problem than a solution.

Kappelman (2000) indicates that these projects “were extensive and complex” and due to “lamentable software practices” correcting them was “very difficult” (p. 42-43). Those projects consumed more than half of the IS operating budget. He indicates that the Y2K total global cost was between $375 and $750 billion dollars (p. 43). What was remarkable, was to find out that “COBOL accounts for approximately 34% of all applications although only approximately 16% of all professional programmers work with it” (p. 34). It is really unbelievable that with such a disadvantage, the world was able to avoid major consequences caused by the 6-digit date standard. We can think of the Y2K issue as a major technological “spring-cleaning affair” just before the new millennium. It was an enormous cleaning task! (See Table 1)

Magnitude of the Y2K Mess


Number of apps

Apps with Y2K problems (%)

Number of files

Files modified (%)

Screens and reports modified

Hardware upgraded or replaced (%)

System software and utilities upgraded or replaced (%)

















Table 1 (Kappelman, 2000)

Outsourcing became the new frontier for American companies. Even though it has declined, it is now one among many solutions companies use to become more competitive. Looking for ways to cut cost by taking jobs away from middle class Americans became a liability. Outsourcing was a solution to a lack of talent problem at that time; regardless, some companies abused it by following the mantra, “I better start outsourcing as many functions as I can…so what can be outsourced must be outsourced” (Friedman 2005, 135), even if talent was available in America.”

Outsourcing became an ‘India versus Indiana’ situation. Friedman (2005) describes a real-world example. When in 2003, the state of Indiana decided to move its unemployment claims to a computer system due to the increase of such claims due to firms that were outsourcing. To do so, it put out to bid a contract. The contract was won by Tata America International, the US-based subsidiary of India’s Tata Consultancy Services Ltd., located in New York City (Friedman 2005, p. 240). Its bid was $8.1 million lower than the closest one, a joint effort of Deloitte Consulting and Accenture Ltd. No firms from Indiana bid for the contract. An Indian company won, and the work was outsourced to their Indian headquarters. But what is ironic, is that Indiana was outsourcing the department that was responsible for dealing with the claims of the Indiana workers affected by outsourcing!

Sadly, the story does not end there. When the details of the contract became public, Republicans made it a campaign issue. It became a political nightmare for the Indiana Governor, a Democrat. The contract was cancelled at the end, Tata received almost one million dollars to cover some expenses incurred. A new set of smaller contracts were put out to bid, so Indiana firms could compete. At the end, the contract became more expensive (and inefficient), but it kept the politics at bay.

Alan Blinder (2005) decided to make, what he called, a bold prediction: “In the future, and to a great extent already in the present, the key distinction for international trade will no longer be between things that can be put in a box and things that cannot. It will, instead, be between services that can be delivered electronically over long distances with little or no degradation of quality, and those that cannot. The tradability of a vast array of services is, as they say, the New New-Thing. And there is little doubt that the fraction of services that can be delivered electronically will grow” (p. 6). That perhaps is the lesson that was hardest to learn, but organizations learnt it very well.


Twenty years after the Y2K problem was solved, information systems have, more than ever, a pervasive presence in every organization. It seems those systems are not only adopted, but they are transforming, sometimes, those organizations to a point that the new trend in businesses is digital transformation. In these twenty years, what have we learned? Are we confident that we will not face another doom’s day because of the programs running our firms?

It is difficult to assess if that is the case. It is clear that the success stories of the first two decades of the 21st century are computer-based business models; Google is the new library, Amazon is synonymous with online shopping, Twitter is the new Fourth Estate, and Facebook is the new Commons. Let’s not forget that these companies rely on the algorithms that make them what they are. Those algorithms were coded in computer languages, some of them use directly or indirectly COBOL sources.

The echo of Santayana’s (1905) maxim “those who cannot remember the past are condemned to repeat it,” is constantly present. It is important to learn the lessons of the Y2K bug. What the programmers were thinking when creating their applications in the late 1950s and early 1960s. How COBOL became a standard in business computing. How the Internet came to the rescue. How outsourcing, as a business model, emerged. All of these important reminders of depending on technology mediating human relations.

What can we learn from the Y2K crisis? By tracing the contribution of those, who by becoming aware of a looming crisis, rang the warning bell to save us all, those who proposed a solution, those who implemented it, those who quantified it, and those who took advantage of new business models emerging from that crisis. It is clear for us that this story of bugs, languages and business models is a way to keep the history of a crisis averted, a crisis that some call Y2K: The bug that failed to bite (Story & Crawford 2001) ignoring the large amount of evidence that if the bug didn’t bite is because the systems were debugged and there were few instances where it was not fixed, such as the welcome panel at Nantes’ Central School on January 3, 2000.

Bienvenue sign
By Bug de l'an 2000 - Own work, CC BY-SA 3.0,

If we ignore the evidence and forget the history of this event that united business and computer professionals, then we most likely will face a similar situation. Another by-product of this lesson is to see how some solutions to faced problems become problems themselves, i.e., outsourcing. Students particularly need to learn this history, be inspired by it, and be motivated to continue the work of building safer and better systems. Managers as well can learn about understanding the systems they adopt, and being proactive to have in house, skills needed to guarantee that such systems run impeccably.


Arranga, Edmund C. and Wilson Price. (March-April 2000). Fresh from Y2K, What’s next for Cobol? IEEE Software, Focus – Guest Editors’ introduction, 16-20.

Blinder, Alan S. (December 2005). Fear of Offshoring, Princeton University Center for Economic Policy Studies, Working Paper, 119.

Bolles, Spencer. (January 18, 1985). Computers Bugs in the Year 2000. Newsgroupnet.bugsUsenet: [email protected].

Callaway, Erin. (March 24, 1997). COBOL comeback, PC Week, 131+,

FIPS. (1968). Federal Information Processing Standards Publication 4. US Department of Commerce, National Bureau of Standards.

Friedman, Thomas. (2005). The World is Flat: A brief history of the Twenty-First Century, Farrar, Straus and Giroux.

Heidegger, Martin. (1993). The question concerning Technology, in D. F. Krell (Ed.) Basic Writings: Ten Key Essays, plus the Introduction to Being and Time, Revised & Expanded Edition, Harper Collins:307-341.

Kappelman, Leon A. (March-April, 2000). Some Strategic Y2K Blessings, IEEE Software, 42-46.

Lohr, Steve. (2001). Go To: The story of Math majors, Bridge players, Engineers, Chess wizards, Maverick Scientists and Iconoclasts – The Programmers who Created the Software Revolution, Basic Books.

Lyons, M.J. (1981). Salvaging your software assets (tools-based maintenance). AFIPS Conference Proceedings, 50, National Computer Conference, AFIPS Press.

McCallum, J. C.  Memory Prices 1957 – 2019 available at

Murray, Jerome and Marylin Murray. (1984). Computers in Crisis: How to Advert the Coming Worldwide Computer Systems Collapse, PBI.

Rose, Ted. (December 22, 1999). “Who Invented Y2K and why did it become so Universally popular?” The Baltimore Sun.

Santayana, George. (1905). The Life of Reason: or, The phases of human progress, Volume 1, Scribner.

Story, Jonathan and Robert J. Crawford. (2001). Y2K: The Bug that Fail to Bite, Business and Politics: 3, (3), 269-296. DOI: 10.1080/13695250120104515

Alejandro Ramirez, “Of Bugs, Languages and Business Models: A History.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1 (Charles Babbage Institute, University of Minnesota, June 2020): 9-16.

About the author: Alejandro Ramirez is an Associate Professor at the Sprott School of Business – Carleton University in Ottawa, Ontario, Canada. He has a PhD in Management – Information Systems (Concordia), an MSc. in Operations Research & Industrial Engineering (Syracuse), and a BSc. In Physics (ITESM). He has been active with the Business History Division of ASAC since 2012 and has served as Division Chair and Division Editor. He is interested in the History and the stories of Information Systems in Organizations. Currently working on a New Frontiers in Research funded project “Imagining Canada’s Digital Twin” with colleagues. ([email protected]).


Back to top


Where Dinosaurs Roam and Programmers Play: Reflections on Infrastructure, Maintenance, and Inequality

Jeffrey R. Yost, Charles Babbage Institute, University of Minnesota

Abstract: This short essay examines two temporally separated crises (current unemployment system failures and Y2K), focusing on connections between infrastructural (largely COBOL-based) IT systems, maintenance, and societal inequality. (KW: computer history, unemployment system infrastructure, maintenance, COBOL, Y2K, inequality).

(PDF version available for download.



grace hopper
Rear Admiral Grace Murray Hopper was an unparalleled leader in the early software field. In addition to her pioneering work with the A-0 compiler, her FLOW-MATIC was particularly influential. More than any other language, FLOW-MATIC provided a model for the COBOL development team. (Image: United States Navy)

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.

Jean Sammet, COBOL Co-developer. She was the first woman president of ACM, a visionary leader. Sammet had a long and distinguished career at IBM. Despite prolific achievements and stellar intellectual and managerial contributions to her company and her field, she was not named an IBM Fellow, an honor granted disproportionately to men—approximately 90% of the 275 IBM Fellows are male (Image: Charles Babbage Institute Archives)

The following month, Hawes’ call evolved into the founding Conference on Data Systems Languages (CODASYL), sponsored by the U.S. Department of Defense (DoD). CODASYL’s ongoing efforts drew inspiration from Sperry-Univac’s Grace Murray Hopper, her FLOW-MATIC, and her advocacy for languages approximating English syntax. For these important contributions, Hopper is sometimes referred to as the “Mother of COBOL,” (Common Business-Oriented Language). Despite some crediting her as its “inventor,” a CODASYL committee of six—Howard Bromberg (RCA), Howard Discount (RCA), Vernon Reeves (Sylvania), Jean Sammet (Sylvania, joined IBM in 1961), William Seldon (IBM), and Gertrude Tiernery (IBM)—developed COBOL. DoD published COBOL 60 specifications in January 1960, eight iterations followed, the most recent in 2014. It began as a standard for the DoD and became a standard of American National Standards Institute (ANSI), and International Organization of Standardization (ISO). Today, though still widespread global technologies, common descriptors for mainframes and COBOL are dinosaurs and dinosaur code.

Still Coding After All These Years

To highlight COBOL’s staying power, and perhaps glimpse into its future, in 2014 the Defense Contract Management Agency (DCMA) stated it was not looking to replace its system composed of two million lines of COBOL code (handling 330,000 contracts worth $1.2 trillion), but re-upping on COBOL. DCMA put out a statement “bragging” its new COBOL system would “probably be around for another 20 to 30 years” (Mazmanian 2014).

Back in 2004, IT research firm Gartner, Inc. had estimated there were two million programmers knowledgeable in COBOL—eight percent of all programmers globally—but that the number was decreasing at five percent a year (King, 2020). 

Today, almost half of banks in the U.S. run systems programmed in COBOL, and 95 percent of all ATM transactions rely on COBOL (Allyn, 2020)—trillions every day. Even in normal times, demand for COBOL experts exceeds supply.

Early Quincy ATM by Burroughs Corporation. COBOL code was and remains the backbone of ATM transaction processing. (Image: Charles Babbage Institute Archives).

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

Women at Plato
Women students at PLATO terminals at University of Illinois in 1963. Women’s participation in CS as majors increased as the field gained traction in the 1960s and 1970s, and percentage of women peaked in the 1980s. Since then there was a sharp decline to a low plateau. This lack of gender diversity holds back CS and IT labor in all specializations, including legacy. (Image: Charles Babbage Institute Archives).

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 ( 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.

Control Data Institutes (CDI)
Both university courses and those at IT vocational schools like Control Data Institutes (CDI) were critical to teaching a generation of COBOL programmers in the 1960s and 1970s—many now retired. Here we see a CDI classroom in 1967. (Image: Charles Babbage Institute Archives)

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.

Global digital divide map
As this United Nations’ graphic shows, the global digital divide is profound. Ramifications during a global pandemic are extreme, where digital connectivity influences opportunities to shelter, connect, and safely earn income. This map is not intended to and does not capture the deep digital divide in the U.S., along class and race lines. (Image: Dakman5, granting public domain rights, Wikicommons)

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.

Unloading CD mainframe
Unloading a Control Data 3600 mainframe in 1964 at Tata Institute, Bombay, India. Both the IITs and Tata were fundamental IT educational and vocational infrastructure that allowed a major software and services industry to prosper in the 1990s with COBOL Y2K compliance work and much more. (Image: Charles Babbage Institute Archives)

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

35W bridge collapse
Minneapolis Interstate 35W Bridge collapse, August 2007. Physical infrastructure gets far more federal support for states than ethereal software infrastructure. Both require evaluation, audits/checks, and timely maintenance—or they break—for software in the form of crashes, delays, breaches, etc. (Image: Kevin Rofidal, United States Coast Guard. Wikicommons. Public domain USCG Image. 17 U.S.C. § 101 and § 105).

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.

History Matters

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.”, March 5, 2019.

King, Ian. (2020). “An Ancient Computer System is Slowing Giant Stimulus.”, 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, “Where Dinosaurs Roam and Programmers Play: Reflections on Infrastructure, Maintenance, and Inequality.” Interfaces: Essays and Reviews in Computing and Culture Vol. 1 (Charles Babbage Institute, University of Minnesota, May 2020): 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.


Back to top

Enjoying Interfaces? Join our email list for future articles and news updates from CBI.