The Analog Revolution

Paper books and vinyl records: they’re not just for hipsters anymore. I’ve tried to hold back on commenting on this cultural shift toward more analog products, because it’s such an easy target for jokes. But I think it’s time for us to face the inevitable: there’s a very peaceful and quiet revolution happening right under our noses. And those of us who work in software have to start paying attention to it.

Article Continues Below

The evidence for this shift is all around us. Craig Mod’s recent essay on reading made a big impact online. In Future Reading he describes his journey there and back again—from paper books to going all-digital for many years, to an almost unconscious shift back to paper. What’s interesting about the article is not only what’s there, but what’s not. Gone is the nostalgic longing for “the smell of books” that is the butt of so many jokes. In its place we find arguments for the tangible benefits of reading non-digital books—their permanence, their design, their readability.

Closer to home, a friend told me recently that he went back to buying CDs because he needs the physical reminder of what’s in his music library. Digital music just kind of disappears once the files go “in the computer.” As for me, I’ve been bearing the brunt of my friends’ ridicule for a while now, since I went back to buying vinyl records. Yes, I think they sound better than digital music, but my reasons also have a lot to do with permanence and tactility—it’s an activity I can enjoy with my daughters, and something that will hopefully bring back positive memories for them once I’m long gone and they sort through their (inherited) collection. And I’m clearly not alone in this.

All of these thoughts have been swimming in my head as I reflected on what I really want to talk about in this column: the idea that “software is never done.” This has become a rallying cry in our industry—a way to push ourselves to constantly make things better. We use those words for anything from excuses to ship terrible MVPs, to arguments with engineers about why we need to move that button 3px to the left. Some of the consequences of this meme are good. Continuous, incremental improvement is a good thing. But there are also some bad parts.

It isn’t that long ago that software actually was done when it came out. Only a couple of decades ago, new operating systems showed up on a CD-ROM and we made VHS videos about how to use them:

When Windows 95 came out, it was done. Yes, there were some patches to it, but they were few and far between, and in general quite difficult to come by. But of course, then the internet and app stores happened, and suddenly everything changed.

The thing about “software is never done” is that sometimes the software gets better, but often it does not. Talk to any long-time Evernote user about the product changes over the past year and see if they’re able to contain their rage. Take a look at the recent release of Paper by FiftyThree and how this beloved product has become close to incomprehensible. Last night I just wanted to watch something, but when I turned on my PS4 I had to wait ten minutes for it to update. I have no idea what changed. Everything still looked the same. But hey, software is never done. Even our updaters need updates sometimes.

Contrast this way of looking at the world to the architect’s view of the buildings they design. Here is Jennifer Fraser in What I Bring to UX From Architecture:

As an architect, the implicit permanence of designing a building carries with it a sense of responsibility… I can’t help but wonder if we would have better designed products if some of that responsibility and sense of permanence of architecture found its way into what we do as user experience designers.

And here’s Tony Fadell, talking about the creation of the Nest thermostat:

Fadell looks out at the Manhattan skyline and says that he always wanted to be an architect; that buildings stay beautiful forever but digital devices are quickly obsolete. “You look at hardware or software five years later? They’re crap. You would never use them again. People use architecture all the time.”

His voice rises. “What is our form of architecture? What is the thing that lasts of beauty?”

So I wonder. I wonder what would happen if we felt the weight of responsibility a little more when we’re designing software. What if we go into a project as if the product we make might not only be done at some point, but might be something that lasts for a while? Would we make it fit into the web environment better, give it a timeless aesthetic, add fewer unnecessary features, and spend more time considering the consequences of our design decisions?

All of this brings me back to the analog revolution. I’m fascinated by our renewed passion for things that are permanent (warts and all) and tactile. I think we need to take that trend seriously, and it needs to influence the way we make.

To make this more concrete, I think we need more software that has ties to physical objects. I know we’re a bit disillusioned with the “Internet of Things”—and for good reason. But I know we can do better. Designers like Josh Clark have been thinking and writing about this for a while. It’s within our reach to bring some physicality to some of our designs.

Most importantly, I think we need more software that’s done—not all of it, just more of it. Just like we’re always going to have prefab buildings to serve a particular function at a particular time, software that continues to change and improve pushes us forward and is absolutely necessary. But maybe it’s ok for that app you’re working on to be done. And by going into it with a realization that it’s going to be done some day, you might even make something that lasts for decades.

We don’t have to give up on digital products, or fight the analog revolution. But we must learn from it, take what’s good, and throw away the rest. And on that note, let’s at the very least agree that dragging a file into a trash can isn’t nearly as satisfying as crumpling up a piece of paper and throwing it over your shoulder.

5 Reader Comments

  1. Great article. I agree in theory that as a developer I’d be very proud to put out a “complete, done” product that people would use for decades. That also entails a few things that seem hard to achieve in today’s environment: 1) the enormous amount of research and development required to make sure the product you deliver meets all the requirements of the majority of your users, and, 2) the buy in from your company to spend the time required (on the planning, and R&D, testing, etc.) to release a product that can stand the test of time without anything more than minor bug patches released in the future. Seems like that’d be a unicorn (and really fun to work for) company. For personal projects, my wanting it to be good enough to last before releasing is what keeps my “always in progress” shelf full. 3) And I guess, as you mentioned, I think it’s because software can change that users expect it to, even if it was good enough at the time. If one part of our lives wasn’t changing so rapidly, maybe we wouldn’t feel the need to look for the things to hold onto that don’t (books, records, etc.). Thanks for sharing your thoughts.

  2. Thanks Dave, great feedback! I should clarify that I don’t think done = perfect. I guess a more accurate expression would be “Software is never perfect.” But I think that’s ok. As long as we meet a user need well (utility + usability), I think it’s ok for some (emphasis on *some*) software to declare themselves done. Pinboard comes to mind. I don’t think there’s been a (visible) update for years, and I still use it multiple times per day.

  3. Great article. I have read it with a lot of interest altough I disagree in some topics, specially in the way the physical things (classical engineering) and software are being comparated. I think most problems of the called “Software crisis” are due the fact of the software requirements change more rapidly and it’s not possible to take in mind in the analysis but I agree about the sensation of “done” things like old fashioned games like the ones of LucasArts. (Sorry for my english)

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

A Content Model Is Not a Design System

Why do so many content models still look more like design systems rather than reflecting structured data? Mike Wills takes us on a personal journey as he examines his own past experiences and invites us to conceive content models that articulate meaning and group related content together for use on any channel.