How do we anthropomorphize software, and why?

To anthropomorphize something is to attribute human qualities to it, whether it actually has those qualities or not. Compugeeks do this a lot, maybe not everyone but many of us. It's quite common to hear someone talk about what a particular piece of code thinks, or to say that a particular server is unhappy, or that a system is confused, and so on.

This was going on long before there were LLMs and I'm not even sure people do it more with LLMs than with ordinary code, though it has a distinctly different flavor with LLMs ("No, stop trying to patch the kernel so my parser's unit tests will pass. Why do you want to do that? What are you even thinking??")

We do this even though we know perfectly well that fifty lines of Python aren't thinking anything at all, and that an LLM-driven coding agent isn't actually trying to be annoying. Anthropomorphizing isn't treating something non-human as an actual human. We attribute some human qualities but not all.

To take an example, sorting a list of things into a given order, say, alphabetically, is a very useful operation because it enables fast algorithms like binary search. It's much faster to find a particular item in a sorted list than in one in a random order. If you give such an algorithm unsorted input, it won't behave correctly. If you track down a particular case of this happening, you might say "It expected the input to be sorted" and even "That's not its fault. We need to fix whatever gave it the unsorted input".

In a case like this, the code is standing in for the author. The author used an algorithm that required sorted input, with the expectation that anyone calling it would actually provide sorted input. As long as that's clearly noted, the author did their job and it's not their fault if the code fails on unsorted input. In other cases, we interpret behavior in terms of human behavior.

To take another example, if a server that normally runs without incident suddenly starts reporting a lot of errors, you might say "That server is angry," because it is very visibly reporting that something is going wrong. If a server tends to get bogged down due to some internal issue and start rejecting requests, you might say "It's in a mood", as in something like "Our service had to reject requests because the server it calls for FooService was in a mood". Or you could say it's "feeling unwell", or any of a number of other things. The common thread is that the server is not behaving as it usually would, and the reasons aren't clearly understood.

As far as I know there's not really a geek-standard way of saying such things, and what people say may well depend on the details of how a service tends to act. In other words, servers can have personalities.

What sort of human traits do we tend to attribute to software? Some of the more common ones are

• Knowledge: "It doesn't know whether this list could be shared, so it has to make a defensive copy"
• Goals: "It's trying to call FooService, but FooService is down, so it just sits there in a loop"
• Emotional and physical states: "FooServer is angry/unwell" "This code will get confused and panic if you give it unsorted input"
• Communication: "FooServer and BarServer talk to each other" "The executor asks the coordinator for the next task to execute"

Are there any human traits that can't be attributed to software? Probably not. Metaphors are fundamental to human thought and people can be very creative in applying them. Nonetheless, some examples come across as deliberately fanciful

• "FooServer and BarServer are scheming together to make sure this query fails"
• "This system lives in a happy world of unicorns and rainbows"
• "FooServer is lonely because no one wants to talk to it"
• "This code has decided that existence has no meaning and all results are equally valid"

The more I go over this, the more I think there's nothing special here about computing. We anthropomorphize all sorts of things: Other animals ("That cat is happy"), vehicles ("It's not a pretty car, but it's been a loyal friend through the years"), the weather ("The sun is trying to poke its way through the clouds") or really anything that can act on its own, or even appear to. Software fits very comfortably into that category.

As with metaphors in general, anthropomorphizing can be nearly invisible, as with the executor asking for tasks, or deliberately vivid, as with deciding existence has no meaning, or somewhere in between, as with not knowing whether a list could be shared. When a metaphor is conspicuous, we recognize it as such. When it's not, we just use it.

Postscript: In re-reading, it struck me that the examples I gave, like "parser's unit tests" and algorithms that expect sorted input, are more than a little dated. While it's not impossible that a working software engineer would end up writing a parser or a function that requires sorted input, if you're designing a web service you're much probably more concerned about things like UX on the front end and scaling and security on the back end. I stuck with the examples anyway for familiarity. Topics like parsing and binary search have been taught continuously for generations, so they're universally familiar, unlike whatever I was working on last week.