A Tiny Miny Picture
The Bra Dilemma
According to my experiences, a small tie shaped silk band located between the cups is an essential part of a modern bra as well :) I don't know why it is omitted in the above image...
Anyway, my observations about the women's demands from a bra are
- Women want a bra to support their breasts and they want to achieve a sexy and healthy bosom posture.
- Women want a bra to protect their breasts and nipples from aggressive glances.
- Women don't want a bra to be realized as an underwear. They want bras to be hidden.
Three observations in contradiction. Number one stresses that women want their breasts to attract attention, they want them to seem well and be realized by others. Number two highlights the women's feeling of hiding their breasts from the outside world. So in here, we can consider the bra as the armour of the breasts. And number three says that women want to appear in a natural way, they do not want to reveal the fact that they are supporting and protecting their breasts by using an artificial thing.
What is this? Too complex to understand... Too complex to live with...
I tnink that this unnatural complexity is the fault of the men dominated social life. Naturally, women never want to hide their breasts under some uncomfortable garments which presses over and make them sweat and scratch their delicate skin all day. But they want to be in the ideal feminine shape defined by the men's desire. As James Brown said, "it is a man's man's man's world"... Moreover, they want to feel secure against the men's gaze and disturbance that annoys women very often in daily life. So the market produced a product that supplies those complex and meaningless demands: The bra. And its contradictions. The following advertisement is a good example of the absurdity that forces the bras exist:
Some social movements exist under the brand of topfreedom and I hope they broaden fast. Topfree Equal Rights Association (TERA) and Bara Bröst (Bare Breast in Swedish) are good and most popular ones in action.
I know that I sound too feminist as a man. However, I believe that humanity needs to simpilfy the over complex, traditional and dogmatic issues of life to step forward in civilization. We don't need to undergo those dark and vague spots which choke open minded human beings. I consider those spots as tumors of the social system.
The life is unique and we have to glorify the life itself and ourselves. Let's open our eyes and see the naked truth. Are we that brave?
Engineering versus Aesthetics?
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:
- Coupling: The level of interdependence among modules. You have to make the module interfaces clear and simple. Low degree of coupling is better.
- 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.
- 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.
- Fan out: Number of subordinates immediately called by a module.
- Fan in: Number of modules that invoke (call) a module.
- 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).
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".