It’s funny that we build “software” and yet, so much of the time, our technical community does not particularly value softness.
How do we explain this?
What makes software soft?
What makes software “soft”? It’s hard to find an adequate account of this because language evolves gradually, following obscure histories. But the history of the word is somewhat illuminating.
The term software is defined in opposition to hardware. “Hardware” is an old word that historically has not had too much philosophical baggage, as far as I can tell: in the sense of “small metal items,” the word entered the English language in the early modern period, when it meant “ware (such as fittings, cutlery, tools, utensils, or parts of machines) made of metal” (per Merriam-Webster). The term dates as far back as 1419, while the related term “hardware store” entered circulation by 1789.
The term software, by contrast, is a decidedly 20th century invention. Some say it first appeared in print in 1958 in an article by statistician John W. Tukey. Tukey wrote:
Today the “software” comprising the carefully planned interpretive routines, compilers, and other aspects of automative programming are at least as important to the modern electronic calculator as its “hardware” of tubes, transistors, wires, tapes and the like. (src)
You can see the scare quotes suggesting that at the time, this terminology was a neologism, not standard usage.
It’s unlikely that Tukey had coined the word. The engineer Paul Niquette, in an odd online autobiography (archive), recounts having discovered the term “software” as early as 1953, while working on the early computer SWAC. He says he had the following “epiphany”:
I was thinking to myself that I wanted nothing to do with the SWAC “hardware” – that the machine was the mindless means for executing my programs – a necessary evil, mostly evil. It was about at that moment, I seized upon the consummate reality of what I was doing – that what I was doing was sharply different from what [the hardware maintainer] Dr. Whitcomb was doing – that what I was doing was writing on a coding sheet, not plugging jacks into sockets, not clipping leads onto terminal posts, not soldering wires, not bending relay contacts, not replacing vacuum tubes. What I was doing was writing on a coding sheet! The exclamation point was right there in my thought back then and in my memory now.
It was October 1953 and I was experiencing an epiphany. Before my eyes, I saw my own markings carefully scrawled inside printed blocks on the coding sheet. They comprised numerical “words” – the only vocabulary the computer could understand. My coded words were not anything like those other things – those machine things, those “hardware” things. I could write down numerical words – right or wrong – and after they were were punched into cards and fed into the reader, the SWAC would be commanded to perform my mandated operations in exactly the sequence I had written them – right or wrong.
The written codes – my written codes – had absolute power over Dr. Whitcomb’s “hardware.” Then too, I could erase what I had written down and write down something different, then punch a new card and insert it into the deck. The SWAC, slavishly obedient in its hardware ways, would then be commanded to do my work differently – to do different work entirely, in fact. The writing on the coding sheet was changeable; it was decidedly not hardware. It was – well, it was “soft-ware.”
This terminology was new in the 1950s, but it emerged from a longstanding current in intellectual history. The software/hardware divide is arguably just a new permutation of a long-standing dualism in European philosophy, according to which there is a radical difference between mind and matter, the ideal and the physical.
You don’t have to read too much Plato to see how strongly-rooted this kind of dualist view can be. And it usually comes with a preference for one side over the other: the ideal gets valorized, the merely physical gets put down. That’s what Niquette was doing when he declared that software had “absolute power” over the hardware, which was “slavishly obedient” to the software’s “commands”. Mind over matter.
At the same time, in an interesting wrinkle, software was imagined as metaphorically soft because it was more “changeable” than the hardware. It’s easy to think new thoughts and write new code, while it’s hard to wire up new circuits: that’s the argument.
Does it make any sense, though?
Two kinds of “hardness”
Hardness means several quite different (orthogonal) things, two of which tend to get mashed together in talk about software vs hardware.
- Hard as in metal.
- Hard as in difficult.
But these are not the same. At all.
Physical hardness is something you test in an engineering lab, for example by applying a known amount of force to a surface and measuring the resulting indentation. Metals tend to be hard in this purely physical sense (though they aren’t always).
Difficulty meanwhile has nothing to do with physical properties alone, and has everything to do with the relationship between an acting subject and a practical task. What’s easy to one person can be difficult to someone else; difficulty is relative to your capacities to solve a given problem in the world.
Dumb example: swimming can be very hard, experientially, even though nothing about the water is physically hard.
This suggests to me that it doesn’t make much sense to assume that “software,” by virtue of being a set of computer procedures and not a bag of bolts and wires, has any intrinsic softness in the sense of malleability, ease of change.
Software isn’t easy to change, actually
I would go farther: it’s just false that software is easier to change than hardware. Niquette argued that “The writing on the coding sheet was changeable; it was decidedly not hardware.” But all this shows is that changing the code was easy for him. Who’s to say what was easier for the hardware specialist Dr. Whitcomb across the room?
In truth, even for software professionals, “software” often isn’t very easy to change. On the contrary. Software problems can be absolutely intractable. Programs are complex systems that can seem to resist your efforts to alter them. All working software developers have had the experience of finding that a simple change is impossible to implement in the time available.
Software can be hard.
The people who talk about how easy it is to change the software… tend to be people who just happen to be good at software and not especially good at hardware. I’m not great at hardware - I’ve never built a computer from scratch (though that would be fun). I can splice a wire and build a thing or two with an Arduino and that’s about it. Hardware is hard for me.
But this is saying more about my own particular expertise than anything else.
Meanwhile, I’ve met electricians who can wire all kinds of amazing hardware from scratch, and would never be able to write a computer program. Software would be super hard for them. Nothing “easy to modify” about it.
The kind of hardness that software people like
As it turns out, software people seem to really like hard problems. There’s even a prestige associated with working on clever algorithms, fancy architecture, large-scale systems and loads. There’s a corresponding disdain for “easy” problems: CRUD apps, small-scale projects, following existing patterns.
Certain kinds of difficulty, of course, are preferred over others. Logical and computational difficulty are valued; organizational, political or emotional difficulty, often much less so. In this, we’re still a field that’s captive to the nerdy technocratic values of 1960s engineering culture.
I just started reading Emily Chang’s Brotopia. It explains in detail how this nerdy culture was partly invented by psychologists, to the great detriment of women in tech. I’ll have to write more about that sometime.
In any case, there’s something more than a bit gendered about what’s valued in software culture and what’s not. For example, we don’t give as much respect to “soft skills” as we could, and these have a historical association with femininity. Skills such as reading the room, relationship-building, empathy, caretaking, and sociability are not highly valued by the nerdy side of programming culture.
It’s sometimes assumed that these interpersonal skills are also “soft” in the sense of being easy and nontechnical. They can be cast as something that programmers can disdain. They probably shouldn’t be called “soft” in the first place; we can distinguish math skills from social skills without alleging that one is more technical, harder and more prestigious than the other. Skills are just skills; there is no clear hierarchy of them. And it seems to me that all the “soft skills” are good for everybody, of whatever gender, and are not necessarily easy to acquire either.
There may be other kinds of softness to think about as well: I’m not sure how to think about this systematically. Maybe we should not be so quick to use softness and hardness as metaphors for things in the world in the first place.
But I would also say that there is nothing shameful about softness. To the extent that it is used to describe valuable things in the world, I wish it were more highly valued in the software field.