Analogies between how things are made in the software world and how things are made in the non-software world are fraught. Software is different, and an analogy that shares one common aspect subtly makes you think that there are other aspects in common, but this is rarely true. 1
This is particularly problematic when developers compare building and shipping products made of software to products made of atoms. Their respective creation processes are dramatically, radically different, even though they do share a couple of aspects. 2
Unlike atom-based products, there is virtually no marginal cost in manufacturing software. Once you’ve made one, you can make a billion for no additional cost. 3
For the user, learning how to use most atom-based products is trivial compared to learning how to use the simplest software product. So while the costs for making and shipping are low, the costs to the user for adopting (or even just assessing) are high. 4
This same dichotomy holds true for design. In the physical world, design is all about constraints. In the software world, constraints are there, yes, but opportunities for imagination are orders of magnitude greater. 5
Donald Shön’s assertion that “design is a conversation with materials” is accepted as a noble trope by industrial designers. But it doesn’t really apply very strongly in the interaction design world. 6
IxDs are constrained by the user’s mental models far more than they are by the moldability and squishiness of plastic. 7
IxDs are constrained by the wacky development processes that software engineers use far more than they are by the machinability and weight of metal. 8
I have very high regard for industrial design and its practitioners, but industrial design is a far, far different practice than is interaction design. 9
Far too many designers in the software world imagine that their training in print design, aesthetic design, and/or industrial design arms them to do credible interaction design. I don't see it. 10
An atom-based product get fully designed, prototyped, and tested BEFORE it goes into production. And the production itself is designed, prototyped, and tested, too. In the software world, none of that happens. Shit gets built and shipped while it is getting designed. 11
All of the time, I hear digital practitioners compare software design, development, and deployment with atom-based “equivalents” and they are simply NOT EQUIVALENT. You have to go to first principles without comparisons to be truly clear. 12
Now, you will notice that my own writings are full of analogies and comparisons with other fields that don’t track fully with software. But doing so demands caveats, callouts, asterisks, and long explanations like this thread to make clear that such analogies are thin ice. 13
As @GeorgeLakoff tells us, metaphors are the building blocks of how we understand the world around us, so we will make no progress at all without metaphors and analogies. 14
@GeorgeLakoff But that doesn’t mean that we can be unreflective about the metaphors and analogies we use. Software is simply a different medium than others. 15
There are fields of practice that are rich veins of appropriate metaphor to the software world, but I almost never hear them used. Film making, for example, has many similarities. 16
Certainly there are documentary and improvisational films, but in most movies, every little aspect is planned out in excruciating detail in advance, sketched and tested and revised long before any film is exposed. 17
Writing is another potential source of metaphor. Paragraphs are drafted using one process, then revised (and revised, and revised) using another process. 18
These days, the software business is dominated by money and those people who have lots of it to spend. So, the luxury goods business might be applicable. Or politics. I’m sure you can think of other promising fields. 19
