What Makes Beautiful Software?

My family got hit by the flu a couple of weeks ago. We crept into our beds, nibbling aspirins and squinting at the bleak winter sun and our hungry cat from beneath our blankets. To pass the time, I signed up for an audible.com account and got a teaser of Hemingway’s “A farewell to arms,” which I feverishly started listening to. The beauty of the book strikes me – intricate, harsh, poetic – and after 30 minutes, I started thinking, “can software be like this?”

What makes beautiful softwareCan it have the same traits of beauty? Remember, I had a fever, but let’s explore that thought for a minute or two.

From time to time I’ve heard people say “that is a beautiful piece of software” – and I instantly knew what they meant. They weren’t just refering to the UI (or perhaps it wasn’t about the UI at all), it was something about the flow in the application, how you interact with it, the integrity of its functionality, and the stubbornness it has when sticking to one domain or solving one problem. It’s how the software opens your eyes and allows you to solve your tasks in new and intuitive ways, without getting in the way.

Can this “beauty” of software be quantized or industrialized? Perhaps not, just as it is with other works of art, but I think there might be some common traits:

  • Integrity – beautiful software solves one problem, and does it better than any other. It sticks to its ways. It doesn’t stray away from its goal and flirt with other seductive functionality. Instead, it relentlessly stays true to its domain. Also, it stays true to its “tone” with the user. It might be a bit harsh in exposing its features, but it does so consistently, and doesn’t apologize. Its consistent both when it shines and when it doesn’t, and you’ll know what to expect and what not to when exploring a new version or update.
  • Usability – beautiful software teaches you the dance even though you are new to the music. It guides you through the tasks at hand in a clear way, minimizing risks for misunderstanding or misuse of its features. It foresees your needs at every step, nudging you in the right direction, keeping you away from the wrong features. It makes the obvious usage easy without removing the possibility for advanced users to harness its full potential. Heck, it might even look good!
  • Innovation – beautiful software is not afraid to solve the problems at hand in new and amazing ways, even if they’re totally different than what you might be used to (or maybe because of that). If you’re a software aficionado, you know what I’m talking about here; this is when some feature or interaction in an application just says “click.” You’ve never seen the approach before, but once you see it you can’t understand how you got along without it, and it makes you think about the domain with new eyes, seeing new opportunities (and threats) that you weren’t aware of before.

Please note that none of these are strictly related to technology; the choice of scala or ruby or F# or cloud or mobile or NoSQL or whatever isn’t enough to make an app beautiful – not in my eyes at least. Although I can definitely appreciate beautiful code or software architecture, it’s not a required trait for beautiful software in the end-users’ hands.

A key requirement for creating a beautiful app is a true product vision, nurtured by its creator(s), the product owner and the product team. This vision needs to engulf the whole product from day one, and can’t be expressed in a backlog or as a user-story. It’s a gut feeling and drive that has to be there, and it has to be allowed to thrive without being pushed back by processes and analysis.

This can be a tough call to make for management; trust the vision of the product owner to navigate the product through the storm, even though some decisions or priorities might not be in line with what competitors are doing or users are asking for.

Here comes an attempt to boil this down to some hands-on advice:

  • Maintain, trust and foster your product vision.
  • Stick your chin out and don’t be afraid to innovate.
  • Love your users and invest in their interaction with your software.
  • Maintain your integrity – fight for it and don’t stray away from it.

I’ll give an example of mine. Many years ago, I did screenshots mainly by alt-print-screen and ms-paint. It worked fine and got the job done. Then someone showed me Snagit, a tool for creating screenshots, and I was completely blown away. SnagIt added so many useful twists to screenshooting – I had never imagined how much better and fun it could be. And just when I thought I got it, I discovered more features that made my screenshots even more appealing (because that’s what it’s all about). Snagit had (and still has) all the above: integrity, usability and innovation.

I’ll end with another beautiful experience: Chet Baker and “That Old Feeling” (opens on spotify) – which is just what I get when working with beautifully crafted software out there, hopefully made by you!


P.S. Do you have a great example of “beautiful software”? Please share in the comments below for us others to marvel at – thank you!


See also:


  1. Hi Graham, 
    Thanks for sharing! I definitely agree that Dropbox fits in this category – it just works and never disappoints 🙂 
    I think you have a good point in regard to lack of code/architectural quality and its (eventual) effects on the quality of the product in the eyes of the user – perhaps it would be interesting to try to do some kind of quantitive analysis of for example open-source projects on sourceforge or GitHub in this regard – using some kind of static analysis tools and correlating that to downloads/adoption over time. Obviously that will give far from the whole picture of a products quality as a whole – but it might give some indications on (or if) there is a “tipping point” when technical debt starts to “harm” a product. 

  2. For me at least, Dropbox is a ‘beautiful piece of software’. The execution of the product is quite simply superb. Easy to use, intuitive and powerful. It is an elegant solution to a frustrating problem and I just love using it. OK, the basic idea has been around for some time (developers using a VCS e.g. SVN, CVS etc.). But they took that technology and made it available for everyone and not just developers. Brilliant. And it…it just works. Simple. 
    “Although I can definitely appreciate beautiful code or software architecture, it’s not a required trait for beautiful software in the end-users’ hands.” 
    True. But being a developer myself, I always try to design our software/code with ‘beauty’ or ‘elegance’ in mind. Unfortunately, I have come across some products that look like an Italian sports car on the outside with all the bells and whistles but when you open the hood and take a look inside it is a different story altogether. 
    This may work for a limited time. But for a limited time only. End users and management are happy and the software works. But in my experience having dirty or badly designed code underneath the product will eventually be the product’s undoing. I have seen it happen and it is not pretty. Code in such a mess that it takes weeks instead of days to make a requirement change, days instead of hours to hunt and pin down a bug because the code is just like a big pile of spaghetti. This eventually starts to deteriate the product because release cycles naturally become longer and buggier. Over time the users become frustrated and simply go elsewhere. 
    In summary, my opinion is that the quality of the code and design is directly linked to the quality and success of the product. Maybe not in the short term but definitely in the long run.

  3. There’s over 30 interesting examples of code that different people see as “beautiful” here http://shop.oreilly.com/product/9780596510046.do

Speak Your Mind