Is It Beautiful?

Do we ask the right questions about the software we test? Sure, we may see that our program properly adds numbers or performs sales transactions, but how often do we step back and ask: Is it any good? Does it evince elegance, excellence, or grace? Is it beautiful?

Does it even make sense to ask these questions about software? We tend to think of software as being something concrete, practical, and functional—far removed from the world of seemingly insubstantial or even whimsical constructs such as beauty, harmony, and style. But, even objects that are primarily functional, such as boots, buildings, and backpacks, clearly embody beauty or the lack thereof in their design. If something so trivial as a button can possess or lack beauty, surely software, with the myriad faces it presents to humans, can possess or lack it as well.

So, what constitutes beauty in software? How do we evaluate it, and what do we gain from doing so? Aesthetics, the school of philosophy that deals with beauty, provides the tools we need to address these questions.

As with other grand philosophical ideals, the definitions of beauty are many and contradictory. One could say that beauty is that which attracts one to a design or which evokes pleasure, as opposed to ugliness, which repels or evokes displeasure. One might also posit that beauty is conformance to an ideal. This ideal might be a universal one like unity, symmetry, or harmony, or it may be more specific to a certain medium of expression. The latter are grouped under the rubric of applied aesthetics . For instance, ideals like clarity and minimalism may be aesthetic elements of cartography.

What, then, are the ideals that software should aspire to—that manifest beauty insofar as software can? Suppose we have two programs, each of which is equivalent in purely functional terms. Both perform the same tasks and give results which are equally correct. All other things being equal, the better program is the one that:

• Has source code that is more clearly organized
• Has more effective unit tests
• Has better documentation
• Is more efficient
• Is more robust
• Has a more usable user interface
• Has a more attractive user interface
• Is more accessible
• Is internationalized
• Presents a unified whole
• Makes users feel good
• Inspires confidence

In other words, software that is beautiful distinguishes itself by manifesting qualities that elevate it above the level of merely being functional—qualities that make it pleasant for humans to use, modify, or test it.

By the same token, testing techniques that are friendly to the people doing the testing are preferable to—and more beautiful than—those that grate on testers. Test steps that have a clear progression, are mentally engaging, and yield understandable results are preferable to those that are convoluted, mind-numbing, and inscrutable, even if they both find the same bugs. Scanning through pages and pages of figures to find ones that differ in some subtle way is ugly. A chart that highlights the differences amongst the test results is less so.

But, wait—when it comes to making aesthetic judgments, isn't everyone's opinion equally valid? Aren't aesthetic judgments purely matters of differing taste? After all, what one person finds pleasant may not be the same as what another person finds pleasant.

This is where one draws the distinction between beauty and taste. Beauty refers to things that are universal, while taste refers to things that are individual. If you say that you like a particular painting, you're making an expression of your own personal appreciation for it. But, to paraphrase Kant, if you say that the same painting is