One of the oldest and wettest dreams of managers since the invention of the computer has been that of getting rid of that pesky layer of human programmers in their organizations. A lot has been written about the psychology of programmers, about how to deal with them as human beings, and about how the dialog between managers and programmers is broken. Evidence shows that neither developers nor managers are interested in knowing how to deal with one another, and hence, managers have tried again and again to promote themselves into a programmer-free world.
Of course, this has not happened yet, and it will not likely happen anytime soon.
But to learn the history of programming is to see that every major advance in the field was driven by the quite explicit aim of getting rid of those programmers altogether, in one way or another, and to achieve a degree of control over the quality of the final product.
It is safe to say that such control is an illusion, as all control is.
Let us enumerate some famous examples of technologies that promised to bring some kind of control into the process of programming, or at least to free it from the all-powerful hand of programmers: FORTRAN and COBOL in the 1960s; structured programming and spreadsheets in the 1970s; object-oriented programming and CASE tools in the 1980s; design patterns and UML in the 1990s; Model-Driven Architecture and TDD in the 2000s; DevOps and Agile in the 2010s; and the latest fad, Agentic AI via statistical bullshit machines LLMs, in the troubled 2020s during which these words are being poured.
Given all of these efforts, one would think that software in 2026 would be a flawless product of the human mind, a perfect contraption, reliable in its feature set, and easily maintainable by the teams in charge. Built with safety and usability in mind, with respect for privacy and ecology concerns, and even with aesthetic considerations. Would that not be a safe assumption? Have we not been building software for over 65 years at this point?
(This author will wait for the reader of these lines to stop laughing uncontrollably.)
Of course not. Quite the opposite. If anything, software has bloated to the point where all the common sense that could be safely thrown out of the window has suffered precisely that fate, where every new wave of hype takes the industry into yet another roller coaster tour and where all rationality has long ago left the building.
No wonder many of us are seriously thinking of raising sheep in the Kerguelen Islands, as far away as possible from any software or human beings, for that matter.
(Catches breath.)
The idea of “software factories” is not new, and as many things in our industry, it was an IBM engineer who came up with it: Bob Bemer, one of the original designers of COBOL and ASCII. He published a paper titled “The Economics of Program Production” in annus mirabilis 1968, in which he described the idea of a software factory, outlining three clear goals:
a. Maximizing programmer effectiveness and personnel resources.
b. Minimizing time and costs for original production, changes and checkout.
c. Maintaining the best-conditioned system from a quality viewpoint.
Generation after generation of programming team managers have been trying to optimize these three variables by whichever means required. Developers, like Schrödinger cats aware of the fact that they are in a box with a lethal isotope next to them, have time and again silently boycotted these efforts (for better or for worse), and the resulting patchwork of technologies and approaches has had an effect akin to that of Taylorism in our field.
Precisely, this author made a painful comparison in this magazine almost 5 years ago:
Software workers are the new factory workers of the 21st century; a group of workers whose obesity, deafness induced by earphones worn in noisy open spaces, and carpal tunnel syndrome, are all visual marks of stress and abuse. The invisible ones having mental health issues; burnout, harassment, depression, all conveniently ignored by insurances, managers, and other board members.
And in this new age of LLMs and Agents, they are also the ones that are conveniently laid off, for the sake of efficiency… and also to raise the market price of the stocks of their respective companies. Those CEOs could always use yet another yacht, after all.
Eliezer Talon, in a discussion about yet another modern software factory concept called the “pull request”, wrote that
The problem is that software development organisations are not assembly lines. Most of the effort goes into understanding the problem, validating assumptions, and adapting when we discover we were wrong. Those activities benefit from collaboration rather than isolation.
Bingo. Somehow, even in the age of LLMs, programmers still have a job; if anything, at least to check that the output of those chatbots makes any sense whatsoever. This raises another crucial question, quite uncomfortable for many, about how to train future generations of programmers to have precisely the skills required to distinguish the wheat from the chaff.
As an old man screaming to a cloud, this author thinks that we could still bring a sense of ethics in our future generations of programmers and software engineers, instead of teaching them yet again how to fool an AI interview process to get a job. I thus hope for a management style where control is neither the carrot nor the stick but a healthy consequence of a well-working dialogue between managers and programmers. Maybe it is not too late to dream of that.
Or perhaps, as usual, I am just being too idealistic.
Cover photo by Steve A Johnson on Unsplash.