A better understanding of how aesthetics can be applied to create or judge software designs can help in creating higher quality software development artifacts that are also more enjoyable to create and work with.
Software engineering is a largely creative design discipline, where new designs (both graphical design models as well as code) are created from scratch. Compared to art, there are many targets (e.g. desired functionality) and constraints (e.g. desired quality attributes) that the software engineer must adhere to, but these still leave almost infinitely many ways to create a model that fulfills all those requirements. In addition, for essentially the same model, there are many ways to represent it. Since models and code must also serve to communicate ideas to other people (or to the same people months or years later), the chosen structure and representation are key attributes for the success of the product.
It's a well-accepted hypothesis that the aesthetics of the artifacts produced during software development are an indication of 'the quality': it is very common to comment on designs as being 'beautiful" or "elegant". Such a qualification is used to indicate the apparent quality of the design. Apparently, we make an intuitive connection between aesthetics and quality.
The goal of this assignment is to find proofs, rules of thumb, or examples that indicate a relationship between aesthetics and software quality.
List of Tasks
- Literature study on
- the role of aesthetics in software design activities
- rules and metrics for objectively judging the quality of software artifact (e.g. how well-structured it is)
- rules for measuring/judging aesthetics
- Identify a number of candidate relations between aesthetics (e.g. proportional sizes, complexity, well-structuredness) and software quality (e.g. complexity, efficiency, modularity, ease of maintenance, separation of concerns, ...)
- Verify one or more of these candidate relations on multiple examples by:
- assessing aesthetic qualities (e.g. through aesthetic rules or human judgements)
- assessing software qualities (e.g. by applying software metrics)
- checking for correlations between the above
- Aesthetics of Class Diagrams (2002) by Holger Eichelberger, in Proceedings of the First IEEE International Workshop on Visualizing Software for Understanding and Analysis
- Helen C. Purchase, Matthew McGill, Linda Colpoys, and David Carrington. 2001. Graph drawing aesthetics and the comprehension of UML class diagrams: an empirical study. In Proceedings of the 2001 Asia-Pacific symposium on Information visualisation - Volume 9 (APVis '01), Vol. 9. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 129-137.
- Peter Molzberger. 1983. Aesthetics and programming. In Proceedings of the SIGCHI conference on Human Factors in Computing Systems (CHI '83), Ann Janda (Ed.). ACM, New York, NY, USA, 247-250