Engineering versus Aesthetics?

A couple of weeks ago, I was a participant of a discussion, which was about "aesthetics in software". I must confess that -as a programmer- motivating myself as if I am producing an art work while I am programming computers is a good way of self satisfaction. It makes you feel elite, you might consider yourself as Michelangelo Buonarroti sculpting the David :)
At this exact point, my friends, I am inviting you to bad-sad reality. The reality says that Michelangelo examined hundreds of cadavers for mastering on the anatomy which is essential for coming up with the real aesthetic values like David, Moses or Pietà. You've got to know the veins, muscles, bones and connective tissues well for being able to create realistic aesthetic art-works. It is necessary to know those fundemantals even if you are willingly to create surreal works of art, because you need to decompose the parts first and then, compose them in your own way again which you cannot do if you know nothing about the rules of connections between the original parts. We have to accept the truth that all those bloody anatomic parts and the idea of cutting the dead bodies in detail do not sound well and it might be hard to relate them with fine arts in the first stage. But this feeling of us does not change the reality...

When it comes to software, we cannot refuse that it is likely to find factors of easthetics in software products. Where are those factors coming from? My immediate answer to this question is Mathematics. Software itself is an implementation of a mathematical approach and we know that mathematical approaches may sometimes be very aesthetic. Besides, a software product might still be beautiful even its mathematical origin is very plain. At this time, the source of the beauty in software is well engineered design. Actually, I believe and have been experiencing that when you engineer the software well, you usually end up with a beautiful product. I recommend the book named Beautiful Code for having the chance to examine some examples of really beautiful software. My rule of thumb about the software development life cycle is "engineer well first to obtain the beauty". It is the easier way of achieving the beauty in software because the other way dictates that you have to develop a very innovative and smart mathematics like Alan Turing, Pythagoras, Carl Friedrich Gauss and Blaise Pascal did in the past and it sounds impossible for ordinary software developers like most of us. Moreover, aesthetics is a branch of academic philosophy and is not an easy to understand and objective issue. If you are not a philosopher or an artist, you cannot deal with it easily. Plus, coding a computer program is more likely to legislation process than painting, making music or sculpting. We never call laws and acts aesthetic, but they might be compact, universal, efficient, logical, well designed etc. By chance (!) we use the same adjectives for software as well.

My advice to software engineers is: "You are software engineers, not software artist". It is written "Bachelors/Masters of science/engineering" on our diploms not "Bachelors of arts". As the real engineers, simply do your duty in the way you have been thaught at the college. The rest is just a sweet dream.

Things to keep in mind shortly about designing software:

1. Coupling: The level of interdependence among modules. You have to make the module interfaces clear and simple. Low degree of coupling is better.
2. Cohesion: The internal strenght of a module. The module whose internal parts are strongly related to each other and to the purpose of the module is strongly cohesive. High level of cohesion is better.
3. Size and Complexity: There are many software metrics like cyclomatic complexity, Halstead volume, maintenance index, time and space complexity (big-O notation), line of code, function point analysis etc. You have got to know how to use, manage and optimize those metrics.
4. Fan out: Number of subordinates immediately called by a module.
5. Fan in: Number of modules that invoke (call) a module.
6. Scope of effect (SoE) and Scope of control (SoC): SoE is the collection of modules that contain code dependent to a decision. If a decision called D located in module M affects the execution of 3 modules: M1, M2, M3 then SoE(M) = {M1, M2, M3}. SoC of a module is the collection of subordinates of the module and the module itself. Te rule is: For module M, SoE(M) must be a subset of SoC(M).

After those design issues, there are, of course, many more issues to consider about the quality of the software such as: Usability, Reliability, Portability, Maintainability, Functionality and Efficiency.
Actually we, the professionals of the industry, are not working for finding the beauty but the ways of reducing the total cost of owning a software. That's why we are called engineers. Besides, we can satisfy our artistic appetite by learning the correlation between "the good design" and "the beauty".