Indeed [Chris said that the Sowftware Artist is *not* a metaphor] . Metaphor (in this context) is a conceptual tool to trigger creativity through unexpected relations between apparently different subjects. It is used both in software world and in traditionally pure arts world.
---
[Shrini asked about performance vs. productivity]
Both terms go with both. I will try to give counter examples:
-On musical creation, we talk a lot about productivity. For example, you have modern jazz artist Anthony Braxton who releases dozens of albums a year. In classical music you have famous people who were extremely *productive*, despite living only 30 years, and other that compose very few pieces, but got famous anyway.
I remember earing this kind of conversations back when I studied in the conservatory of music.
The value of productivity is arguable, some may do more with less. This is true for software world and for arts. Of course when we talk purely about money, we always want "more" (and that is also true for both worlds.)
-When designing a piece of software, sometimes there are problems, like a feature we don't know exactly how to implement. On my company, there is a guy which is known for always finding great solutions. He is known for his *creativity* in working around hard problems.
Maybe there is a problem with the words. In a previous post Chris suggests using "create" instead of "write" or "code", or "build". This seems a great idea.
.....
Sorry I used "creativity" on my previous post instead of "performance", but the reasoning is still simple.
Word performance is used in engineering fields very often: note how it was used in marketing language for describing new car models ("modelxxx has a great performance off-road") so that people get a fast intuitive idea of an overall caracteristic of that vehicle.
We could equally say "John has a great performance as an exploratory tester", or "the new kernel has a great performace on that scenario"
-----------------
Michael Bolton describes metaphor even better than I do:
Actually, "is like" denotes simile, not metaphor. What you'resaying--something like "software IS art" is metaphor, quite distinct from"software IS LIKE art".
>I thoroughly do not intend for The Software Artists to be interpreted as anunsupported metaphor.
That's too bad, because metaphors rule. In addition, metaphors don'trequire support or references or citations. Metaphors are models that (aslong as we're paying attention and participating in the exercise) highlightboth the similarities and the differences. Metaphors get their powerprincipally from the cognitive friction that gets generated from equating(not merely comparing) something with something else that is manifestlydifferent AND manifestly the same.
---Michael B.
Thursday, June 5, 2008
Wednesday, June 4, 2008
Software artists explained
Shrini, thanks for your always critic thoughts.You put some phrasing that is not my own, if you read carefully my post you see I say:
"engineering is also a form of art, in what relates to creativity, beauty and emotion drive"
and
"Every piece of software we create [...], has a beauty that will echo [...]"
which is not the same as saying:
"all engineernig is art" (typo kept)
but I get your idea, so I will try to explain a little better.
I think there is a continuum between the two extremes: the complete mechanical process (call it automated, or automatic) and the human or artistic process.
Take some examples:
On a painting, for example, there is a large amount of work that is technical, like the materials, inks, brushes and the painting technique itself. There is also a lot that is conceptual, emotional, artistic.
On a musical instrument same applies: technique, sound engineering, scales, arpegios, etc are ideally automated "under the fingers", so that our mind can search more musical ideas.
So these activities, although traditionally from the "art" field, often consist of 90% of mechanics and 10% of art, if you know what I mean.
Now for the field of engineering:
-Suppose my job is to test a piece of software.I will get to know the business context, so I can explore some useful scenarios - just a painter will focus on a theme and explore it;I will place myself on a end-user position, try to see what means value to this product - just as an artist who is constantly evaluating his workSometimes I will complain because the GUI does not communicate the idea I think it should, thus misleading the user - sometimes music fails to communicate, doesn't "click", as well.
So, just to resume my point, I don't think "everything is art", but instead that we can learn a lot if we see the processes that are traditionally not artistic, through an "art lens". Particularly through the use of metaphors, that are everywhere in art, but also in software (for example, a button is a metaphore for an action. Sometimes the button is there only so we can notice we can do something)
This said, I would like to add that we cannot separate the artistic individual from the practical individual inside each one of us, although we use in different moments one or the other (some say it is located in different zones of the brain...)
"engineering is also a form of art, in what relates to creativity, beauty and emotion drive"
and
"Every piece of software we create [...], has a beauty that will echo [...]"
which is not the same as saying:
"all engineernig is art" (typo kept)
but I get your idea, so I will try to explain a little better.
I think there is a continuum between the two extremes: the complete mechanical process (call it automated, or automatic) and the human or artistic process.
Take some examples:
On a painting, for example, there is a large amount of work that is technical, like the materials, inks, brushes and the painting technique itself. There is also a lot that is conceptual, emotional, artistic.
On a musical instrument same applies: technique, sound engineering, scales, arpegios, etc are ideally automated "under the fingers", so that our mind can search more musical ideas.
So these activities, although traditionally from the "art" field, often consist of 90% of mechanics and 10% of art, if you know what I mean.
Now for the field of engineering:
-Suppose my job is to test a piece of software.I will get to know the business context, so I can explore some useful scenarios - just a painter will focus on a theme and explore it;I will place myself on a end-user position, try to see what means value to this product - just as an artist who is constantly evaluating his workSometimes I will complain because the GUI does not communicate the idea I think it should, thus misleading the user - sometimes music fails to communicate, doesn't "click", as well.
So, just to resume my point, I don't think "everything is art", but instead that we can learn a lot if we see the processes that are traditionally not artistic, through an "art lens". Particularly through the use of metaphors, that are everywhere in art, but also in software (for example, a button is a metaphore for an action. Sometimes the button is there only so we can notice we can do something)
This said, I would like to add that we cannot separate the artistic individual from the practical individual inside each one of us, although we use in different moments one or the other (some say it is located in different zones of the brain...)
Tuesday, June 3, 2008
Software Artists
I think this theme is definitely important, and I believe in the present and near future people are realizing this reality. So I congratulate you for this article.
Now for the critic...When you split between engineering and art, I tend to disagree. I think engineering is also a form of art, in what relates to creativity, beauty and emotion drive. For example, the beauty of a construction: one may argue that the architect is an artist, but the engineering itself can be beautiful, for instance, on the simplicity of the structures, the way the light enters in the inside (this is really an engineering problem). The effort of the engineer was drived by his feelings, his ideas, and the emotions he placed on the future of the users for the house.
More generally, I think there is no world where we can drop the art, as we cannot drop the feelings. Every piece of software we create, every test we design, every chair we build, has a beauty that will echo when someone else will see our mind through that work (of art)
--- "Chris McMahon" wrote:
>
> A couple of times on this list I've mentioned starting what I call the
> "Artistic School" of software development and testing. I think it's
> critically important to have intellectually rigorous descriptions of
> software practice that are *not* based in the language of
> manufacturing or engineering.
>
> To that end, I have published The Software Artists:
> http://chrismcmahonsblog.blogspot.com/2008/05/software-artists-index-of-links-to-all.html.> This is an attempt to describe software practice in the language of
> art and performance instead of manufacturing and engineering.
>
> I"m interested in comments and criticism on the paper. I vacillate
> between thinking it's either the coolest thing I've ever written, or
> completely and totally irrelevant. It might also be just a mildly
> interesting failure.
>
> Anyway, if you read it, let me know what you think.
> -Chris
Now for the critic...When you split between engineering and art, I tend to disagree. I think engineering is also a form of art, in what relates to creativity, beauty and emotion drive. For example, the beauty of a construction: one may argue that the architect is an artist, but the engineering itself can be beautiful, for instance, on the simplicity of the structures, the way the light enters in the inside (this is really an engineering problem). The effort of the engineer was drived by his feelings, his ideas, and the emotions he placed on the future of the users for the house.
More generally, I think there is no world where we can drop the art, as we cannot drop the feelings. Every piece of software we create, every test we design, every chair we build, has a beauty that will echo when someone else will see our mind through that work (of art)
--- "Chris McMahon" wrote:
>
> A couple of times on this list I've mentioned starting what I call the
> "Artistic School" of software development and testing. I think it's
> critically important to have intellectually rigorous descriptions of
> software practice that are *not* based in the language of
> manufacturing or engineering.
>
> To that end, I have published The Software Artists:
> http://chrismcmahonsblog.blogspot.com/2008/05/software-artists-index-of-links-to-all.html.> This is an attempt to describe software practice in the language of
> art and performance instead of manufacturing and engineering.
>
> I"m interested in comments and criticism on the paper. I vacillate
> between thinking it's either the coolest thing I've ever written, or
> completely and totally irrelevant. It might also be just a mildly
> interesting failure.
>
> Anyway, if you read it, let me know what you think.
> -Chris
Subscribe to:
Posts (Atom)