Six Attributes of Beautiful Systems

At Squarespace, one of our most important values is:


We work to bring excellence in design not only to the tools we create for our customers but also to the code and systems that power them.

On the surface, aesthetics and technology are not obviously related. The idea of beauty is not traditionally within the scope of software engineering which is typically concerned with algorithms, measurable elements such as time and space, performance, and abstractions. Yet, at the same time, engineers can be caught saying:

That’s a beautiful solution.

The essential difficulty is this: good design is plainly recognizable in objects that you can actually see and touch (such as art, cars, clothes, furniture, food, or buildings), but software is intangible and purely logical. In other fields, a creator can advance her craft because there exists a language for critique; a painting, for instance, is described in terms such as line , texture , movement , scale , or tone . Even the world of beer has a rich lexicon: full bodied , malty , yeasty , hoppy , etc.

It’s unclear how software engineers are supposed to judge similar qualities in their work. Faced with this challenge, numerous questions have come to mind:

What does it mean for an abstract thing like software to be beautiful? We “know it when we see it” — but how does one actually go about creating it? Is it possible to isolate and articulate a set of properties that we can use to judge our work so we may critique and improve it? If so, what words would we use? Given that we care about good design at Squarespace, how do we marry aesthetics with code?

What Is a “Beautiful System”? Why Bother?

What I’ve learned at Squarespace is that technical aesthetics can be described precisely and that developing that vocabulary to use in conversations with colleagues about the merits of designs can lead to more beautiful systems, which carry significant practical benefits. Such systems are:

  • Easier to use, operate, maintain, and scale
  • Longer lasting and are more extensible far into the future
  • Powerful — solving more use cases with less complexity
  • Adaptable to new requirements
  • Simpler to test

Fred Brooks, author of The Mythical Man-Month , also wrote a remarkable book called the Design of Design . One chapter deals with what he calls “technical aesthetics” and sketches out ideas for how one could identify a logically beautiful system. In this post, I’d like to elaborate on this idea and show you six attributes of beautiful systems accompanied by specific, actionable tips, as well as examples, so you too can identify them in your own work. The same principles are applicable at every level, from the human interface all the way down to object design and method signatures. You should come away armed with a precise vocabulary for the aesthetics of software which you can share with your peers, leading to better and longer-lasting designs.


a.k.a. “Minimalism”

a.k.a. “Lean and Mean”

Parsimony is the ability to accomplish a great deal with few elements.It is marked by less conceptual clutter and fewer ways to do the same thing. Parsimonious systems are relatively more usable and learnable simply because there are fewer things to learn, fewer decisions to make, and fewer items to sift through to reach the things you need. They are also inherently safer, leaving fewer ways for you or other engineers to make mistakes in the future; fewer operations equals fewer unsafe operations.

In general, being aggressive in removing the extraneous is like scraping the barnacles off of a boat, which pays dividends in the long run in the form of less drag. In a parsimonious system, there are fewer moving parts to monitor, refactor, maintain, test, and to teach to other engineers who join the team. Such minimalism is probably the single biggest factor in determining how fast you can go. Remember: “Deleted code is debugged code.”

The Test: Ask Yourself...

For any construct in your system, ask yourself: is this actually just the combination of two other things? Is it redundant with an equivalent thing? If so, remove it!