At Squarespace, one of our most important values is:

DESIGN IS NOT A LUXURY

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.

1 PARSIMONY

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!

Good

Bad

Good – The CMYK color system is richly expressive with only four base components. Virtually any image can be rendered with these.

Bad – There are countless different types of screws on the market, many of which exist for very specific situations, and all require different tools for driving.

Example: PHP

PHP is an infamously non-parsimonious language. Numerous functions provided out-of-the-box exist for obscure use cases, such as:

ucfirst() converts the first character of a string to uppercase.
fgetcsv() gets a line from a file pointer and parses it for CSV fields. The same result can be achieved by simply composing two other existing functions: fgets() and str_getcsv().
join() and implode(), which are aliases of one another. One could be deleted.

A Word of Caution

Parsimony, like many of the other attributes in this post, is positive only up to a point, so beware of following this to the extreme. Excessive parsimony leads to the use of non-obvious idioms.

Example: A Non-Obvious Idiom in a TV Remote

For an Apple TV (4th Generation) remote, the same button that takes you to the home screen is also used for turning the device off. As a user, you must somehow possess knowledge of the fact that you just have to press and hold the button down to turn it off. This is a non-obvious idiom. If, as a designer, you introduce enough of these idioms, you create what’s commonly called a “learning curve.”

2 STRUCTURAL CLARITY

To have Structural Clarity, there must be a direct path from what you want to say to how you say it. This principle is largely focused on representation and reducing indirection.

Do most people prefer to type obscure commands into a command line interface just to launch a notepad app, or simply tap an icon with a finger? Do you prefer coding in assembly or in C? Do you prefer a list of GPS coordinates or a map with a drawn route? When the level of representation matches the level at which you are thinking about the problem, it can be said to be structurally clear.

To be clear, the concepts of your system have a structure to hang on and it must be plainly evident. A common way to achieve this is with familiar metaphors, such as the “Desktop” of Macintosh, the “spreadsheet” of VisiCalc, or the “blocks” of Squarespace.

Example: Two Ways to Model the Same Data

When designing data models, you are making structural decisions about representation. Which of these is clearer?

TransferRecord	Refund
direction: -1	amountRefunded: "10.05"
amount: 1005	currency: "USD"
currencyID: 1	forCharge: “31f0alq8xz710a0”
parentTxID: "31f0alq8xz710a0"

Structurally, the design on the right will be clearer to others. There is less indirection than on the left, where several fields must be interpreted to have meaning (they must somehow know that direction -1 means a reversal, know that currencyIdx 1 corresponds to US dollars, etc.)

3 CONSISTENCY

Given familiarity with just part of a system, you can predict the rest of it. Note that Consistency does not mean that everything is the same. I’d call that “uniformity,” where if several elements were the same, then they’d be redundant and you’d follow Parsimony to eliminate them! Rather, Consistency requires there exists an underlying principle uniting all the elements and ensures some form of compatibility. The principle should be simple to state. For instance, you’d expect that all functions in a package try to maximize reuse and throw similarly formatted exceptions, use similar error codes, and take similar input types. It yields designs which are not only very usable and understandable, but also unlocks interoperability between elements.

Example: ISO 216 Paper Series

Good Example	Principle
A Paper Series (ISO 216)	Each sheet in the series is 2X the size of the previous sheet
Metric System	Each unit is 10X bigger than the last
Vitsoe 606 Universal Shelving System	All shelving modules have a standard width and are mountable anywhere on the tracks
UNIX pipes	All inputs and outputs are plain text
Phoenician Alphabet	All words are composed from 22 symbols, each has a sound

All of the above systems can be explained in a single sentence. With consistency, code is literally shorter , requires fewer tests , and is more resilient to change. When you introduce a new element to the system (say, a new feature module to the shelving system, or a new program in your UNIX toolbox, or even a new letter to the alphabet), you will not need to spend effort reworking other components in relation to it: a unifying principle ensures the newcomer easily “plays nice” with the rest.

Inconsistency, on the other hand, is incredibly expensive. If all your microservices outputted their logs in different formats, it’d be impossible to aggregate their outputs or easily search across them; engineers will need to learn the various eccentricities of each in order to debug issues. The cost to your organization due to inconsistency ends up being O(N) rather than O(1), where N is the number of things you’re maintaining. Allowing overhead to grow at that rate is unsustainable and eventually can be crippling to your development speed.

Bad Example: JavaScript Type Coercion

JavaScript type coercion is a famous example of inconsistency. Depending on what the arguments are, what operator you use, or even in what order you place the operands, the result might be a string, a number, or an object. To a developer, there exists no discernable reason or underlying principle to explain the erratic behavior.

Screen Shot 2018-07-14 at 1.53.58 PM.png