In the midst of the recent brouhaha about Markdown1, Craig Mod posted an interesting tweet about the nature of software. In response to John Gruber’s assertion that the original version of Markdown doesn’t need a significant amount of work, he said this:
@gruber @waxpancake I think your point about it being ok for software to be “done” is very strong. We need more “done” software.
— Craig Mod (@craigmod) September 5, 2014
This gave me pause, because it flies in the face of a very common mantra in the design world. Sure enough, it didn’t take long for another big name in Design to throw down the words many of us have said over and over:
@craigmod @gruber @waxpancake Software is never done.
— iA Inc. (@iA) September 5, 2014
This happened a while ago, but I can’t stop thinking about it. Craig is one of my favorite thinker-writers (hey, if singer-songwriter is a real word, this is totally a real word as well), so I didn’t want to treat it as just another easily-refuted throwaway comment.
The fact is that it isn’t that long ago that software was actually done when it came out. It’s only a couple of decades ago that software showed up on a CD-ROM and we made videos about how to use it:
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 in full force, and suddenly we decided that “Software is never done”. In some sense this is certainly true. There are always bugs to fix, things to improve, more features to add, unused features to remove — and of course, the SaaS model makes it all so easy. But I wonder if we’ve taken this a bit too far.
A fairly recent example that comes to mind is email software Sparrow’s acquisition by Google. Man, did we freak out about that one. The thing is though, the software didn’t suddenly stop working just because it was “done.” It was still there, it was still great, and it still works to this day. But that’s not good enough for us any more. Things have to keep getting better and better. And that’s fine — I’m not arguing against progress. In fact, I deliberately turn off automatic app updates on my phone because I love updates and release notes so much.
But I also wonder if our obsession with the never-doneness of software — the inherent throw-awayness of our MVP and test-and-learn culture — is having a negative effect on the quality and lasting meaning of the software we make. I’m reminded of Jennifer Fraser’s words in her article 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?”
Or consider Dmitri Fadeyev’s words in a discussion about Russian architecture:
What’s interesting about this type of architecture is that its aim goes far beyond that of creating a functional underground system. Its aim is to promote a political ideal, and it does it through beauty by enriching lives of the people who get to experience it. The question here isn’t: how do we solve the problem of creating a metro station in an efficient manner – instead the question is: how do we create a station that elevates people’s mood and inspires their lives. This architecture isn’t there just to help you live – it makes life worth living.
I do 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 design we come up with might not only be done at some point, but might be around for 100 years or more? Would we make it fit into the web environment better, give it a timeless aesthetic, and spend more time considering the consequences of our design decisions?
Coming back to Craig Mod’s tweet, I have to say that on reflection I agree with him. 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 Markdown to be done. Or Sparrow. Or that app you’re working on. And by going into it with a realization that this is going to be done some day, you might even make something that lasts for decades.
- The details of the Markdown argument between John Gruber and Jeff Atwood isn’t the point of this article, so don’t worry if you missed it. ↩
