This post is a continuation of my attempt to make sense of Bonnie A. Nardi's A Small Matter of Programming in 2020. It includes Nardi's argument, rephrased and analyzed in a modern context, with some of my commentary weaved in to keep things smooth-ish. I'll look at chapter 2 in this post—check out my previous post for a break down of the book's intro!
Chapter 2: Conversations and Computers
There's a trope about software that permeates pop culture, the technology industry, and virtually any narrative around AI sentience. You've probably seen it—some person talks to their computer, as if it's another person, and it does everything they want them to do. Although I can't speak to the origins of this fantasy, it certainly suggests the idea that computers—with enough progress—can be equivalent to humans. And we've definitely seen this manifest over the past couple years—voice assistants like Google Assistant and Siri are available in everyone's pocket now.
Nardi writes this book in 1993, with the proposition that this approach of conversation is not an appropriate means for communicating with computers—or rather, that we shouldn't design software with the frame of conversation as a default. The chapter deconstructs this notion, where it comes from, and what we can do about it.
For one, it's definitely not easy to have computers understand human conversation. In conversation, there's always context that's hard to grasp—and not just relative to the conversation. A computer might be able to record previously spoken statements to extrapolate meaning from ambiguous syntax, but it won't be able to understand nuanced assumptions related to the political, cultural, or even physical environment.
The practicality of using conversation, Nardi argues, is from it's ability to accomplish goals between humans, and because of this practicality we falsely assume conversation to be the ideal medium for interacting with computers. Nardi's explains this using anecdotes of courtroom conversation, the main takeaway being that there exists inherently practical goals in all conversation. Even innocuous "mundane conversation" has goals, with it's "mundane-ness" sometimes being the goals itself. Even if all nuances of conversation is captured, conversation isn't a "stateless" medium.
...there is no guarantee that features found in mundane conversation...will necessarily result in the same managed accomplishment observed in their original context. (p.22)
We should look to solve these goals, not mimic the medium at which these goals are achieved.
In addition, Nardi mentions that it doesn't really make sense to reduce communication with computers to conversation. You wouldn't "talk" to your car to operate it—automobile interface designers have figured out a much better "coupling" between the driver and the car. Similarly, computers excel at certain tasks, and people (comparatively) at other tasks. This is one of the many reasons why we use precise formal languages (programming languages) to communicate with computers.
...we should ask what it is we want to do with computers, examine the way in which resources are allocated among the parties to the communication, and then determine, based on this assessment of opportunities and constraints, how we can best communicate in the unique situation in which human and machine come together. (p.23)
Nardi closes the chapter by nailing in a point—it's natural to assume that conversational language would be an appropriate alternative to confusing programming languages. However, it is a misnomer to assume the "formal" aspect of programming languages is the barrier (as opposed to conceptual complexity). People use formal languages to communicate every day—it's just not that obvious when we do. How and when this happens will be covered in the next chapter. By understanding this misconception, the door opens to identifying how we can define a "formal" approach to communicating with computers (hint: graphical interfaces!!!!).
So why is this relevant today?
Nardi goes over the specific pitfalls of treating computers as people-substitutes, in regards to interaction. I think it's valuable to extrapolate this to a higher level—we should generally avoid treating our computers as these subservient robotic butlers altogether. There's a general sentiment in the industry that technology "serves" its end users. While there is much truth to this, I would say folks often misconstrue it, focusing on the act of serving end users, as opposed to actually solving larger problems end users have. While there is certainly "demand" driven factors that influence the development of software (instant gratification loops in social apps and negligent growth strategies), as software builders we have to take accountability with the philosophy in which we make software. Are we actually empowering end users, or are we simply telling them all their problems can be solved by our software?
And don't even get me started on the culturally problematic notions of "serving" in software! Like why voice assistants default to feminine voices, or how the deliberate obfuscation of gig workers' humanity leads to literal manufactured classism. Again, this conversation is much broader and deserves more depth of course, but won't be covered in this series.
It sounds obvious, but if we treat computers like computers—and not people—maybe we can reach a world where software empowers everyone, rather than exacerbates existing problems, as it's done for the past few decades. ¯\_(ツ)_/¯
Stay tuned for the next post! We're going to start digging into the meat of this book in chapter 3, and WHEW it's quite a ride. Catch you then! (Hopefully before a month from now this time 😅)