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.