In the Name of Efficiency

I was surprised (and delighted) when this year’s Monktoberfest had two talks on developer productivity — both from the Developer Success Lab. Developer productivity used to be a popular research topic in the 1970s and 1980s, but thereafter faded into obscurity. Many of the books that I have on developer productivity are from that era. I wanted to start with Joan Greenbaum’s 1979 book on this topic, titled In the Name of Efficiency: Management Theory and Shopfloor Practice in Data-Processing Work. The first reason for starting with this book is that it is a callback to the Monktoberfest talks. The second reason is that it explores the topic of programmer productivity through a lens of class struggle between management and labor. The book is peppered with quotes from Marx and “radical theory” — so one might suspect a socialist bias. To be fair, though, she also quotes Taylor and Drucker and McGregor, so one might also argue that there is a management bias. However, when I look back at her thesis through the lens of the various liberal software¹ movements which sprung up years after the book was published, it seems that the points she raised from a Marxist perspective are the same points that were raised by the openly libertarian advocates of those movements. In my previous article I touched upon the two camps of the software liberalization movement. I thought it would be useful to provide a source which suggests that these opposite political viewpoints would lead to the same strategies and solutions. And lastly, the book was written far enough back in time that many of the anachronisms have the effect of sharpening the focus on some of the issues which are more timeless.

With all that by way of introduction, let’s dive in.

In the Summary — the author writes:

We are told that human nature is competitive and individualistic, but data-processing shop-floor actions contradict this. Effective data-processing work is usually accomplished by workers who help one another by sharing knowledge, skill, and tasks.

That would seem to be a succinct summary of the Free Software ethos, the Open Source Software ethos, and (coincidentally) the Marxist ethos. Instead of referring to a “community” of workers (as in “the open source community”), the author consistently refers to the data-processing “shop-floor”. At the time the book was written there was no Internet — in order to work on a computer, you had to pretty much go to where the computer was². Programmers could be located elsewhere in the office, but computer operators had to be in the room with the computer. That gave rise to the “shop-floor” metaphor for computer work. Also, this book, as most books about software development, must make analogies with the automotive manufacturing industry. (Think Scrum and the fact that it was borrowed for software development from Toyota manufacturing.) The reference to the software development community as the “shop-floor” fits neatly into the constant automotive manufacturing comparisons.

But what does this have to do with programmer productivity? Woven throughout the book is the distinction the author borrows from the economist David Gordon who posits that there are two kinds of efficiency: quantitative efficiency (the increasing of measured output) and qualitative efficiency (the minimization of worker resistance) — and that productivity can be affected by either (or both) kinds of efficiency. Efforts to increase quantitative efficiency can lead to decreases in qualitative efficiency (or vice versa). Another way the author characterizes this duality is the difference between individual productivity and team productivity. In measuring the effectiveness of the team, the quantitative measures of the output may not be able to correctly attribute the contribution made by a person who may not be writing many lines of code (or making multiple commits). And my choice of words in the last sentence telegraphs another way the author describes these two concerns; rather than call them two different kinds of efficiency, she suggests that they are two different kinds of productivity: efficiency and effectiveness. This book is more concerned with the issues surrounding effectiveness (which — if you think of them as being about “worker resistance”) are social issues, rather than efficiency (which is more often a technology issue).

An illustrative example from current events would be the productivity arising from the introduction of artificial intelligence tools into the movie industry. One might argue that the use of such tools would increase quantitative efficiency (the writing of more lines of a script per worker per day). However, entertaining such a strategy has led to considerable worker resistance. The impact of the worker resistance has led to a significant reduction in productivity (a lengthy strike).

Another example would be the current debate over policies curtailing working from home and mandating a return to the office. The arguments deployed pit the pursuit of individual productivity against the aspiration for team effectiveness. One can fairly employ the term “worker resistance” in this context.

The author explores yet another framing through the lens of management science.

Within the pages of management literature, for example, efficiency of all resources — both people and things — is determined by the ability of management to control, measure, and predict the outcome of labor process.

In order to improve (quantitative) productivity, management must increase control, increasing worker resistance. Effective management is the finding of strategies to increase control while minimizing worker resistance. In this framing, management is constantly striving to apply the principles of assembly line production — dividing the work into narrow specialties, restricting worker discretion, and creating activities which can be more easily quantified. (Anyone who has worked on an “Agile” shop-floor with timers might recognize this.) By contrast, workers aspire to more agency because they aspire to be artisans. They want to be able to apply their experience and judgement; they chafe under management strictures meant to prevent them from engaging in unquantified or unquantifiable activities.

Redmonk (to circle back to the inspiration for this publication) has also weighed in on the history of this conflict, specifically as it relates to the empowerment of developers in the enterprise (Stephen O’Grady even wrote a book about it: The New Kingmakers³ ). A major pivot in the industry occurred around the turn of the millennium when liberal software allowed software developers to ignore the enterprise software acquired by management for millions of dollars in licensing fees and download free software that they could use without seeking management approval. Management went to great lengths to prevent free software from infecting their shop-floor⁴. Eventually, the workers (programmers) succeeded in seizing control of the means of production (development software). The justification for this libertarian action was that the corporate bureaucracy did not have the right to impose their policies on the freedom-loving programmers. Much Atlas Shrugged was quoted. But I digress.

Back to In the Name of Efficiency. Early in the book (page 18) I ran across one of those “today I learned” facts. I quote:

In 1971, the Department of Labor decided that programmers were not professional employees and therefore were eligible for overtime pay. A federal judge upheld this in a 1976 decision, stating that programmers were not executive, administrative, or professional employees: “Of interest is the fact that a programmer does not need the expertise of the designer, need not know the inner workings of the computer, and can do adequate work with only a general familiarity of its function and a grasp of computer language.”

I was particularly struck by the contrast between the Department of Labor action (which is dated and does not reflect the current state of the industry), and the judge’s observation (which seems contemporary and captures modern prevailing sentiment).

There were so many passages that I found thought-provoking because they could be viewed in the light of changes that happened long after the book was published. Some of these observations seem prophetic in the light of what happened later, while others seem to be completely obsolete. Some of these apparently obsolete observations encouraged me to rethink my opinions about current events, so that upon further reflection, although the observations might not have been prophetic, they now appeared cautionary. For me, the particular philosophies which demanded increased reflection upon reading this book were “Agile” and “Open Source”. I single out those two because they arose long after the book was published. Other areas (like management or hiring or education) existed at the time — so the insights there are more direct.

Another reason I enjoyed this book is that many of the observations about the state of the industry reminded me of my own experiences at the time. A younger reader might find it more eye-opening than reminiscent.

I have not commented on one area that the author explores — the de-skilling of programming — because she quotes from an entire book devoted to the topic, Philip Kraft’s Programmers and Managers, a copy of which lives on my shelf and will be the subject of a future book report.

I will leave you with the final two sentences of In the Name of Efficiency:

Efficient work activities can take place without the management ideology of social control. Examining workplace activities begins to point us in the direction of understanding other forms of work organization.

Is that libertarian? Or liberal? And would “open source software” fall into the category of “efficient work activities without the management ideology of social control”?

If you are intrigued by this book or any other book mentioned in this article, they all have Amazon affiliate links. I might earn something if you purchase a book after clicking on them.

[1] Common practice is to use the term “Free and Open Source Software” to refer to the two main movements that concern themselves with source code. This is an ungainly construction, and I have an aversion to using acronyms under any circumstance — they tend to obfuscate rather than clarify. And what about additional movements that have existed and may yet exist to liberalize software distribution? So I asked ChatGPT: What is an English word which means “free and open”? And it answered:

The English word that means “free and open” is “liberal.” While “liberal” has multiple meanings and can refer to political ideologies, it is often used to describe ideas, policies, or environments that are characterized by a commitment to individual freedoms, openness, and a lack of restriction.

I have to agree with the Artificial Intelligence on this one. “Liberal software” encompasses both Free Software and Open Source Software.

[2] Three years after this book was written, I managed to work remotely for a large New York investment firm from my home in Virginia. I was their very first remote worker.

[3] Sadly I will not be doing a book report on The New Kingmakers because I loaned my copy to someone a while back and no longer have a copy on my shelf. The rules of engagement for this series is to write book reports for “books I have on my shelf”. Which currently means that books that I have loaned or lost are excluded. I am waiting for a ruling from the parliamentarian as to whether books which I only have in digital format are permissible. One could argue that they are on my digital shelf (if I’m using a skeuomorphic reading app).

[4] When I started as the Director of Open Source Strategy at a large New York investment firm, I installed Linux on my machine, and a team of people from the Desktop Support organization came into my office and physically confiscated my machine. It took me a week to get it back. Reducing, I might add, my productivity, and increasing my resistance.