Whether we are consciously aware of it or not, in the midst of development we make hundreds of tiny decisions that reflect a choice in "beauty". Mostly these boil down to a decision for what level of elegance we will apply to a design approach: whether to hack away at something until it works or whether to design the code with an eye toward easing future maintainability.
In the old days we used the shortcut terminology of "table-driven-design" to signify the latter case, but nowadays designing for maintainability is much more than this (see for example these earlier posts).
For now though consider this interesting metaphor to beauty: just as a person can suffer equally from both too much beauty or too little beauty, the same can be said for the elegance and maintainability of a software system. If something is hacked together in an ugly and hasty fashion then not only will you have to support it forever, but you will grow gray or lose all your hair in the process. Conversely if you design something that can be maintained and extended simply by adding rules to a SQL table then your employer doesn't really require your continued ongoing services.
You must therefore choose an appropriate level of elegance in the same way that people choose their level of beauty. This has all sorts of philosophical and aesthetic consequences that I examine in a different category.
