From: Dennis Newbold Date: 2002-05-13T13:32:30+09:00 Subject: Re: OT:is software eng an art? Interesting question. You invited opinions, so here's mine. 1. I once read an interesting quote of Knuth pertaining to this question. Basically, he said that -- science is what we understand well enough that we can tell a computer how to do it (e.g., compute a missile trajectory, balance a checkbook, etc). Art is everything else. Using that definition, I doubt that we can say the process of writing computer software is yet a science, because we can't write a computer program that can write a computer program -- go through the decision making processes, algorithm selections, dividing the problem into a no. of smaller subproblems that interact together properly, etc. There are some limited domain areas, such as parser generators, etc. that show some progress in that area, but, in the general case -- no. Perhaps the best example of this (although it really needs none) is: Ruby itself. No one, not even matz could write a computer program whose output would be the Ruby scripting language. So, if we accept Knuth's definition, writing computer software is not a science. 2. Its not an art either. Art justifies its existence by being beautiful and aesthetically pleasing. Now, don't jump all over me just yet here. I am as aware as anyone that computer software can be very aesthetically pleasing (at least to those who can read it. Don't expect any spontaneous sighs when you show your latest creation to your wife / kids). The point is that even the most pleasing software both in terms of pleasure creating it, and pleasure reading it, justifies itself by WORKING -- by accepting input, and producing a desired output. And, if it can't do that, we're not all that interested in keeping it around (unless we like to tinker, and try to get it to work). Art doesn't have to work. It just has to be beautiful. Computer software has to work. That's why I prefer the term artisan to describe what most of us do every day. We are not artists, but we are artisans -- we make things that work well, and that are also aesthetically beautiful. And the most cool thing about working with software (I know I'm preaching to the choir here, but I have to say this anyway --) is that in general, and with some care, the goals of beauty and utility are complemetary rather than adversial. We can write programs that are more useful and work better specifically because they are beautiful. I think that Ruby itself is an excellent example / case-in-point here. 3. Any artist or artisan who is beginning to learn their craft must first learn to discipline him/her self to the proper use of their tools, and of their mind. Neither science, art, nor artisanry can be effective without some form of discipline or structure. The tricky part is just balance -- too little or too much (particularly that which is externally imposed by people who do not understand the software engineering process) can hinder production and effectiveness. The right amount can enhance it. Finding the right amount can be a tricky process. But the best way to do it is when you impose a discipline upon yourself that you can buy into, and enhance your own output as a result thereof. In summary: not science, not art, artisanry the best practitioners produce a happy marriage of beauty and utility the right amount of engineering discipline is self-sought, self-discovered, and self-applied. Take care. Dennis --------------------------------------------- | | | The way to be happy is to be good | | | --------------------------------------------- On Sun, 12 May 2002, Phil Tomson wrote: > I signed up for a free seminar that's being held at a grad school nearby > where I live. The title is: "Read My Lips--No New Models!" (or perhaps it > might be more accurately titled "We don't need no stink'in new software > development methodologies!") You can read the abstract here: > http://cpd.ogi.edu/class.asp?n=02-SPIN-0513 > > I suspect it's a reaction against XP, so I figure I'll go and ask some > pesky questions ;-) > > Anyway, one of the points made in the abstract at the website above says: > "# The misguided notion that software is art and hence not amenable to > discipline" > > Now I've seen this assertion many times: > "Software Engineering is a discipline not an art!" and other varients. > > However, I would contend that Software Engineering _is_ an art or a craft > and that by admitting it we actually dignify the practice instead of > denigrating it (the folks that say that it's not an art seems to be afraid > that if the term 'art' is applied to software that it will somehow become > cheapened). > > Why do I say that software creation is an art (or craft)? > 1) It's a creative, human endeavor. > 2) Each of us brings his/her own personal style to the creation of a piece > of software. I attended a ceramics show last weekend where there were > several exhibitors and demonstrations. I could definately tell that > certain of the artists had distinctive styles and I got to the point where > I could tell who made a particular pot. It's the same in software - when > you're working with a team of coders after a while you can tell without > looking at the creation comments at the top of the file who created the > code. I get the idea that the "software is not an art" crowd want us to > all have the exact same 'style' (theirs, perhaps). > > To say that calling something an 'art' means it lacks discipline also > seems like a mistake. I recently watched a glass-blower create a glass > bowl - it took lots of education and discipline, but I would still say > that it was an artistic creation. > > Now bringing it to Ruby.... It seems to me that Ruby has a certain style > which is the imprint or signiture that Matz put on the language. Python > and Perl have very different styles from each other and from Ruby and > each represent their creators in distinctive ways. > > So, is software creation an art or a discipline (or a science)? Opinions > welcome. > > Phil >