information architecture & critical history of software (PhD research) in Toronto

view my cv

Quinn DuPont studies the critical history of software technologies, focusing on metaphysical, historical, and political issues. He has recently been studying the history of email and developing an argument about the modes of production for software development. Quinn is currently a MITACS Enhanced Accelerate PhD Fellow and iSchool PhD student in Toronto, Canada.

search
reading
  • Difference and Repetition
    Difference and Repetition
    by Gilles Deleuze
  • From Taylorism to Fordism: A Rational Madness
    From Taylorism to Fordism: A Rational Madness
    by Bernard Doray
  • Questioning Technology
    Questioning Technology
    by Andrew Feenberg
« Review of Beyond Taylorism | Main | Review of From Taylorism to Fordism: a rational madness »
Saturday
Jul302011

Review of Histories of Computing

Mahoney, M. S. (2011). Histories of Computing. (T. Haigh, Ed.). Cambridge  Mass.: Harvard University Press.

Histories of ComputingMike Mahoney’s posthumously published collection of articles and excerpts covers little new ground for those familiar with Mahoney’s work, but having it collected in a single (somewhat slender) volume helps contextualize Mahoney’s contributions, and shows his stunning breadth of thought. The Histories of Computing is not only about computing, or at least not as narrowly defined. There are three sections: “Shaping the History of Computing”, “Constructing a History for Software”, and “The Structure of Computation”, which correspond to three of Mahoney’s interests: historiography and methodology, software engineering, and the history of mathematics (as it applies to the history of computing). Each of the three sections have a different feel and seem to correspond to Mahoney’s self perception of his role in the area.

The first two sections, on historiography and software engineering, share considerable ideas and literatures—Henry Ford and Friedrich Taylor make frequent, almost cloying appearances—and are written in a somewhat similar manner. These sections feel mature and confident; capable of making pronouncements on the direction of a (fledgling) field of computer history, and skim over details—as though the author has mastered it all long ago. From what I can tell, this quickness over detail is less a matter of fact than a matter of rhetoric, not that there is much of fault in Mahoney’s analyses.

For Mahoney, it is evident that historiography and software engineering blur not just at the edges, but at their core. In addition to calling for more histories of software, and especially histories of applications software, Mahoney thinks that the history of software in the future must tackle at least one of George Daniels’ “really big questions”. Specifically, future history must explain the “American System” and its culmination in mass production as it relates to the production of software. Mahoney describes the history of software and production under at least four rubrics:

  1. The development of mathematics and computation (discussed in the third part of Histories of Computing).

When Mahoney died in 2008 he left an unpublished monograph on software engineering. Supposedly this monograph was a decade in development, but until it is published posthumously Mahoney’s contributions on software engineering will have to be evaluated on his short, provocative, and exciting published articles and keynote lectures (most of which are published in Histories of Computing). Mahoney’s contributions to the history of software engineering helped create interest in the so-called “software crisis” of the 1960s, to which the 1968 and ’69 NATO conferences on software engineering attempted to address. Additionally, Mahoney frequently invokes the imagery of a Ford factory line, arguing that Fordism is not “merely window dressing” but part of the fabric of software engineering. This line of reasoning is found in the practical and academic discourse from the software crisis of the 1960s to today, and although Mahoney helped pushed this agenda the area remains underexplored. While reading Mahoney’s comments on the “American System” I’m left wondering what Mahoney takes to be essential to Taylorism and Fordism, and just how this impacted software engineering in principle and in practice. Without Mahoney’s unpublished manuscript we are left with caricatures of Ford and Taylor and their respective movements, and still unable to answer the “big questions”.

Nonetheless, in an attempt to historically understand the production of software Mahoney offers a typology of three “models”: applied science, mechanical engineering and industrial engineering.

If software engineering is an applied science, then according to Mahoney its basis is mathematics, which itself must also be a science. In the chapter “The structures of computation and the mathematical structure of nature” Mahoney vigorously defends the view that mathematics is a science, and shows how the theoretical interest in computing for artificial intelligence and automata, formal languages, and formal semantics culminated in a new science. This new science is made clear by McCarthy’s development of LISP and the use of the lambda calculus as a formalism to express the innately mathematical qualities of computing.

The model of mechanical engineering for software production reveals an explicit desire to move software production from pre-Industrial Revolution techniques into the modern era. For this model Mahoney identifies some aspects as parallel, such as modularity of software code and modularity of machined pieces, but the two pages devoted to mechanical engineering leave many of its properties unexplained. Indeed, Mahoney seems to cop to the fact that the model of mechanical engineering bleeds into the third model, industrial engineering.

Industrial engineering uses a different set of techniques to accomplish similar ends to mechanical engineering. The “factories” of industrial engineering are sought for software production, but Mahoney never precisely describes what production techniques within these factories apply to software production. For example, do software factories produce in batches, or in a flow system? Are workers (digitally?) arranged for surveillance? Linear or parallel paths? What provides the transfer of energy for production (the digital equivalence of humans on a table system, or steam-powered machines)? Ford and Taylor both appear as catalysts for industrial engineering, but Mahoney never explains how they differ, or even if he thinks they do differ. Mahoney quotes Michael Cusumano’s Japan’s Software Factories which suggest that software production “lies at a level between craft production and mass production, namely, at the level of flexible design and production systems.” As my review of Forcing the Factory of the Future made clear, it’s highly imprecise to suppose that flexible production lies between craft and mass production: it’s more likely the culmination of mass production, forced through economic pressures and local production cultures.

Although Mahoney is maddeningly terse when discussing factory or craft production of software, and non-committal about the dominant processes, he does explore the constraints offered by the “programming environment”. Mahoney is clear about his intentions: “Two main strains are of particular interest here: the use of programming environments to constrain the behaviour of programmers and the extension of programming systems to encompass and ultimately to automate the entire software development cycle.” As might be expected, Mahoney believes that constraints function to inhibit some behaviour and promote others, but, surprisingly the “programming environment” for Mahoney is not text editors such as ed, ted, or vi, nor source code control systems such as SCCS, RCS, Cedar, or Gandalf, but instead the programming language and compiler. The constraints come about directly—not administrative, nor architectural—to wit, “Structured programming languages, enforced by diagnostic compilers, were aimed at constraining programmers to write clear, self–documenting, machine–independent programs.” These programming languages brought discourses and applications: from ALGOL to LISP for mathematics to be used by AI and theoretical computer science, while FORTRAN and COBOL brought data processing, and UNIX brought collaborative production. What is left unclear is how these constraints correspond to operations research or industrial engineering. For this history I would suggest that we must to turn source code control, management “dashboards” and control systems, and human resource management.

The third section of Histories of Computing is Mahoney’s most impressive, both in terms of breadth and depth. While Mahoney skipped too quickly over much of the history of software engineering, his history of mathematics and its relevance to the history of computing is so precise and so erudite that, as Thomas Haigh says in the introductory chapter, it is written “for an audience that does not yet exist”. The arguments for “the combinatory rather than the analytical” nature of automata, and thus computers is repeated again and again, but not to be left merely stated, Mahoney engages in lengthy discussion of just how the logic works. But, the history of computers is too complicated for such a non-paradoxical statement, and Mahoney thinks that it is tempting to think of computers as (Boolean) logic machines, but with evidence from C.A.R. Hoare and John McCarthy he argues that computers and the all important software running on them are instead, mathematical. Going further, Mahoney argues that, for epistemological reasons pertaining to how we model and understand nature, mathematics is a science, not merely a handmaiden to science. This final part of Histories of Computing is far too challenging to evaluate completely, since it delves into the influences and cross-pollinations of computer history, technical aspects of computer and programming language production and use, and logic and mathematics. Without a doubt, this capstone leaves the reader bewildered at the impressive scholarship contained within.

 


[1] For example, Howard Rheingold’s Tools for Thought, among others.

[2] Mahoney correctly calls the engineering of software merely “engineering”, and not “software engineering” since the models for its development came well before the provocative title of “software engineering” in 1968.