Is It Beautiful?—Aesthetics in Software Testing

[article]
Summary:
With all the faces it presents, surely software can be said to possess or lack beauty. But, what does it mean to have beautiful software, and how do we evaluate it? In this installment of his series on philosophy and testing, Rick Scott takes a closer look at software aesthetics.

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 beautiful, you're saying that everyone else should appreciate it as well. To put the two into stark relief, take the following example: One programmer might prefer a certain style of formatting code, while a second may prefer another. However, both programmers almost certainly agree that code that's consistently formatted to any standard—even one that's not their personal favorite—is superior to code that's not formatted at all.

While testing can consist merely of examining desired features to ensure that they work as designed, this will only guarantee that the resulting software is minimally functional. For it to rise above this level, testers also need to elevate their game. They need both the latitude and the ability to step back, consider the software as a whole, and critique its design. While software aesthetics and human factors tend to get short shift, nobody wants to use software that is stubborn, inflexible, tedious, or unintuitive, especially if there are better alternatives.

Testers can also improve both their testing and their job satisfaction by making aesthetics a first-order consideration when designing tests. Just as software that presents a more human-friendly face to users and developers is better software, tests designed with tester friendliness in mind are superior tests.

Though aesthetics is a quality often derided as superfluous, improving the aesthetic aspects of a software project can yield tangible and pragmatic results. Software that is more pleasant to use than competing products gains an edge in the marketplace. Code that is clearer and easier to modify sees better robustness as bugs are more easily fixed. Tests that are engaging help testers keep their mental focus, resulting in more defects being discovered. While form and function are often discussed as though they can be cleanly separated, excellence in one is important—and sometimes necessary—for excellence in the other.

User Comments

3 comments
Robert Rose-Coutré's picture
Robert Rose-Coutré

Thanks Rick Scott for the great article and insights. Having read Kant's 3rd Critique (Aesthetics) as well as the other 2, it was fun to hear such a reference in a software article. I thought you characterized the facets of beauty very nicely. It sounded like injecting the concept of "well-formed" into every aspect of a software project, which I think is a great idea. Your recipe would make software professionals' workaday life more exciting and rewarding. This is the same as the deep inspiration that a true craftsman gets from his work. It takes more care and discipline, but it's worth it. On the end-user side, beauty in software does have tangible results for the user, it makes the user enjoy using the software more. You can't measure it, but it's certainly tangible to the user. So everybody wins (although you have to sell management on it since it costs more).

For anyone interested, here are two other great StickyMinds articles on "Beauty in Software":

Testing the Bold and the Beautiful

Article by Yogita Sahoo

http://www.stickyminds.com/r.asp?F=DART_2514

Looks Do Matter

Article by Yogita Sahoo

AsiaSTAR 2002 Conference Proceedings

http://www.stickyminds.com/r.asp?F=DART_6273

October 31, 2011 - 2:41pm
Dhruva Ramachandra's picture
Dhruva Ramachandra

Thank you Rick for the lovely article and beautiful thoughts. In my opinion, this will not be allowed or you will no time to implement it. The code or test cases are written as quickly as possible. Testers are always in crunch mode of the project. I would love to implement it in one of my projects. Again thanks for your beautiful thoughts about testing.

November 3, 2011 - 1:21pm
Philip Hoeben's picture
Philip Hoeben

Hello Rick,

I really like the topic, here are some of my thoughts.

I think it's correct to say that aesthetics deals with beauty, but this was up-to-and-including the 19th Century (approximately).

Starting in the 20th century (approximately) with people like Duchamps (ready mades), Warholl (pop-art) and lots of other artists aesthetics wasn't merely talking about beauty, but also about exploring the boundaries of art and by that trying to self-define or re-self-define itselfs.

There is a similarity in testing since there are a lot of discussions about testing going on from different schools, factories, free thinkers (whatever that means) that is actually also about self-defining testing; What is testing, what is good testing, how can we improve testing and so forth.

Just like in aesthetics the testworld is exploring boundaries from the "testing is dead" to testing is an ungoing activity that never ends but only stops (of course there are a lot more boundaries you can think of).

Testing itself is not merely about the easy checks but it might be usefull to also explore the boundaries.

Is there really such a thing as "objective" beauty? Everybody in every culture values a piece of art with the same level of beauty?

This would mean that there is some kind of objective "beauty" in the artwork that tracendents individual experience.

I think not, the way people experience beauty depends really on the context. A button in a software application may look great in product A of vendor A,

but since the user has huge objections to product B of vendor B the experience of the beauty of the same button will probably be much lower here. In fact it's the questions if it's the same button, when the experience is different?

best regards,

Philip

December 12, 2011 - 7:47am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.