More than 400,000 software engineers have lost their jobs in the last couple of years, I wouldn’t be surprised if it’s really significantly more than half a million as some won’t have been documented anywhere that the tracker project saw. In the years leading up to Layoffapalooza, software engineers commanded high salaries (though maybe not universally high) , often with significant perks. Do these shifts in employability privileges reflect a change in the legitimacy software engineering enjoys among its peers, clients, and other stakeholders?
Let’s first identify what legitimacy is. A dictionary definition would have it that legitimacy is something like “the ability to be defended”, so as our working definition for software engineering’s legitimacy let’s use the idea that software engineering legitimacy is the right, or ability, that software engineers have to define their work and their contribution on their own terms. That is, taking as an assumption that somebody somewhere in our society wants someone to write software for them, software engineering is more legitimate if software engineers get to decide what to write, how, and how they’re evaluated, and less legitimate if somebody else (clients, managers, governments, whoever) gets to decide that. This kindof ties legitimacy with autonomy, but it also connects it with status or privilege.
Following Mark Suchman’s Managing legitimacy: strategic and institutional approaches, let’s break this down into three categories. He’s talking about institutions, so I’m pretending to make an assumption here that “software engineering” is an institution. I suspect that some people (both inside and outside the field) see it as such, and others don’t. But it also might be useful to explicitly call out organisations, interest groups, user communities, or other subcultures within the field and investigate whether they are more or less institutional (so that we can
Cognitive legitimacy
The third of Suchman’s categories, cognitive legitimacy is the idea that an institution is legitimate if it doesn’t take much effort to see it as such: in other words, that it’s consistent with the worldview and values that people already have. It’s easy to maintain cognitive legitimacy, though perhaps hard to acquire. But it also doesn’t get you much, as it’s really about existing in the background. An institution that didn’t have cognitive legitimacy might look something like the Communist Party of the USA: every time you’re reminded that it’s there, it’s a surprise and you’re not sure what to make of it.
People pushed for the cognitive legitimacy of software engineering basically from the start of the field. The 1967 NATO working group chose the name because it was illegitimate:
The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.
Indeed the preface to the second of the NATO conferences on software engineering reports of the first conference:
The vast majority of these participants found commonality in a widespread belief as to the extent and seriousness of the problems facing the area of human endeavour which has, perhaps somewhat prematurely, been called “software engineering”.
Brian Randell, who edited the two conference reports, recalls that the second conference attempted to “fast-track” legitimacy; an attempt that failed.
Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on “Masterpiece Engineering”.
Fast-forward 54 years from that second conference, and the phrase “software engineering” is indeed part of the cognitive background of programming computers. But the institutions that underpin it are not. Like other phrases, including Agile, DevOps, and Open Source, software engineering has been co-opted by the managerial class to mean “the people we hire to do the work we want them to do, the way we want them to do it”. Research institutes like the SEI, or special interest groups like ACM SigSoft, don’t have a seat at the software engineering table in the large. Even in academia, while software engineering was meant to base practice on “theoretical foundations and practical disciplines”, it’s common that if software engineering is researched at all it’s a field in the Computer Science department. All theoretical foundation, no practical discipline.
Pragmatic legitimacy
Pragmatic legitimacy is that which supports an organisation because doing so is in the rational self-interests of the audience. A lot of support for open source software is in the form of pragmatic legitimacy: we open source our database because that will encourage grass-roots adoption, which is cheaper than a sales channel. But notice that, as said with cognitive legitimacy, when we talk about open source we talk about a managerial decision to “open source”; we don’t talk about joining the Open Source Initiative, or bringing in a representative from the Software Freedom Law Center to train our attorneys. The idea holds legitimacy if not the institution.
Come down from the conceptual to the project level, and more pragmatic legitimacy holds. An organisation uses Linux, but it doesn’t want to maintain its own Linux source tree, so it’s in that organisation’s interest to accept the Linux Foundation as a legitimate collaborator. In general “upstream” is a legitimate institution: you upstream your changes because it’s in your interest to accept the governance of the external maintainer team.
Moral legitimacy
Moral legitimacy perpetuates an institution because it represents positive values, or “the right thing to do”. A lot of people in the Free Software movement see GNU, and the FSF, as moral imperatives, so occasional missteps in governance can be forgiven or overlooked as they don’t represent the overall trajectory or challenge the belief structure.
In academia, a lot of arguments for research software engineering come from the idea that it’s the right thing to do: making reproducible software, or high-quality software, is good for research, therefore we should do it and rely on the collective expertise of organisations like the society for RSE, or the software sustainability institute, or Better Scientific Software, to help us interpret the needs. But does that align with pragmatic legitimacy, and when it doesn’t, how is the conflict resolved? Is “high-quality software” a strong enough moral imperative among all stakeholders to influence the autonomy of a whole occupation?
