Breaking down old(ish) literature
First looking at "A Small Matter of Programming" by Bonnie A. Nardi
Hey all! It's been a while since my last post, for pretty obvious reasons. There's far better words than my own around what's been going on, and I don't want to belabor the tragedies against Black lives in this quite arbitrary blog.
All I will say in this post is that design—as a discipline—is deeply tied to equity and justice, and there's plenty of folks out there that are far more qualified than me to write about this, of whom I suggest researching on your own. Maybe I'll write more about this in the future, but I'm sure that if you're reading this right now, you already know what I'm talking about.
To follow up on my previous post, the first piece of academic literature I'll be writing about is "A Small Matter of Programming" by Bonnie A. Nardi. I'm going to attempt to break down this book chapter by chapter, re-contextualizing the 1993 exploration into end-user computing philosophy for modern day digital product design. My main goals for writing about this book is:
For myself, to learn how to structure complex thought into digestible information
A principle I will have from here on out is to simplify complex concepts through writing, as much as I can. Academic literature can be scary! Between folks in academia, I believe there's not much reason to scale back the complexity in arguments due to the shared pool of knowledge most these folks are writing in. They are—undoubtably—very smart. I—undoubtably—am not nearly as smart. These concepts are incredibly conceptually dense and abstract! It took me a while to understand some of the text, re-reading to make sure I had a good understanding of what these folks even meant. If I'm going to write about why these books are relevant today, I should be able to explain them in modern writing as well.
For designer friends, to communicate ideas I think are important to being a "good" designer in 2020 and beyond
There's definitely a lot of gray around what a "good" designer is, but one attribute that I am certain of is intentionality (hence the name of this series). Of course, true intentionality comes with constraints and tradeoffs. These writings often look at these tradeoffs in the world of software/digital products, and I believe understanding these arguments will help folks in design become "better" designers (at least in the software world).
Cool! Enough meta-commentary on this series and this book—time to dive in!
Chapter 1: Introduction (yes, I'm covering the intro)
Nardi starts off the book by posing a question that I believe has largely been unanswered, even 27 years after its publication: Why is the power of computing dominantly owned by programmers? It seems kinda silly to ask, right? "Well Justin, programmers can code. Code controls computation. Duh." Well, yes, if you want to look at computation from the perspective of telling your computer's processor what to do. But we both know that computing is far more than that.
If you've used MS Excel or Google Sheets, that's considered computing! Okay, there's some scripting involved there (and I'm not going to dive into the semantics of what's considered "coding"), so let's take it further. If you've adjusted how many notifications are sent to your phone, or even changed your phone's wallpaper, you unknowingly became a programmer, alongside the programmers that made the software you're using.
Yes, you're not exactly building an app, but you're influencing the behavior of software. In a sense, you've made a design decision about the software you're using, harnessing the power of computation to how you'd like it.
And sure, it's not much, but could you ask for more? I mean, software is hard, isn't it? Shouldn't we leave the heavy lifting to those who know how the specifics of computers work? Nardi would definitely disagree. She believes that end-users (the folks using software at the very "end", in modern day just called "users") should be able to program their software to how they'd like it to work.
End users are not "casual," "novice," or "naive" users; they are people such as chemists, librarians, teachers, architects, and accountants, who have computational needs and want to make serious use of computers, but who are not interested in becoming professional programmers. (p.5)
Nardi argues that there's an incredibly disproportionate "underutilizing" of technology. She argues that because programmers are often told to follow extremely narrow specifications for building technology, "many end users never get the applications they want, and their computers sit on the desktop gathering dust." This is from 27 years ago, and it's more or less, still the same today! Of course, there's more "consumer-friendly" software available today, but for professionals, this hasn't really changed.
Okay, got it, we need to build programs that let you program...programs? How would that even work? Well, as I mentioned before, you could get a good idea of this from spreadsheet apps. Nardi will also look at CAD (Computer-Aided Design) tools as another form of "end-user programming" later in the book.
In addition, since this book has been written, a lot of end-user programming has manifested in the form of "productivity apps". Most these apps would probably not satisfy Nardi though. She wants to look at how we could approach complete end user application development—end-users creating software for themselves. The remaining chapters in this book look into technologies that move towards (or away!) from a future where this would exist.
So why is this relevant today?
Well, we still don't really have the end-user programming Nardi wanted. Over the years, software has basically been pigeonholed into highly specific use cases, and so much computational power has fallen by the wayside.
And while there is appeal to the "magic" factor of highly specific use cases, the lack of generalized software often exacerbates existing problems software was born into—a grossly disproportionate distribution of resources, weighted towards those with more capacity to accrue capital.
In theory, computing should be able to absolve this inequity. In practice, we know this hasn't happened.
Although Nardi doesn't dive too deep on this aspect of computing in this book, plenty of other brilliant folks have written on this. Books I think are great at investigating the development of software alongside capitalism are "The People's Platform" by Astra Taylor and "Rise of the Robots" by Martin Ford. Nardi has also published "Heteromation, and Other Stories of Computing and Capitalism (Acting with Technology)" with Hamid R. Ekbia three years ago, although I have not read it (yet!)
Okay, weren't you writing about "communicating design" originally?
Yup. It's actually related! That entire problem is a "subproblem" of end-user computing. If you solve the problem of having folks program applications for themselves, then you will have (most likely) figured out how to communicate design decisions beyond their visual representations.
By investigating that original problem, I had my eyes opened to this broader field, which I believe is more important to write about now. I think it's worth noting that "no-code/low-code" is the other half (or at least another subproblem) of this space. This is sort of how I imagine it:
Next post will be on Chapter 2! We'll look at how Nardi views the effectiveness (or namely, ineffectiveness) of conversational/language-based paradigms for communicating with computers. If you're reading this (and you're not me) feel free to let me know your thoughts! DM me on Twitter or wherever we first were acquainted :)
FOOTNOTES
¹ Nardi isn't the sole source for all these arguments, but I don't think it's necessary to dive into the specifics of who named which concepts. I think that's overkill for this series, but if you'd like to dig into it, I'd encourage you to check out the book!