Fog Creek Software
Discussion Board




Yet another proposal for defect free...

Ok... Lemme ask:  How long are we going to wait for "Software Engineering" (see the purdy fireworks display) to save the world of software development?

I'm serious.  Engineering is about constructing something physical.  The end result is something physical, it can be touched, weighted, evaluated objectively.  It is engineered by observance of the laws of nature.

The end result of software development is yet another abstraction.  Abstraction runs all the way through software development.  At the end, what do you have?  Something that cannot be considered physical (pixel display?), cannot be "touched", has no weight, and if you look at some of the other threads like the one about Word features - is never evaluated objectively.

So, consider this:

"By a selective re-creation, art isolates and integrates those aspects of reality which represents man's fundamental view of himself and of existence.  Out of the countless number of concretes - of single, disorganized and (seemingly) contradictory attributes, actions and entities - an artist isolates the things which he regards as metaphysically essential and integrates them into a single new concrete that represents an embodied abstraction." - Ayn Rand

Anyone for a "Software Artist" mythology?  Why not?

Joe AA.
Monday, July 01, 2002

Good god, where have you been?  See any number of programming as art versus programming as science discussions during the past 20 years.  Half the problem is people like yourself that didn't bother to read any of the previous literature then all of a sudden think you've discovered some brilliant fscking idea.

the cluetrain
Monday, July 01, 2002

lemmee finish.  People objectively evaluate software all the time. 

the cluetrain
Monday, July 01, 2002

and yet again.....  What we have right now is a bunch of artists (hacks) that think they are above {engineering principles|software best practices|plain fscking common sense}.  How would your proposal change anything?

the cluetrain
Monday, July 01, 2002

"and yet again..... What we have right now is a bunch of artists (hacks) that think they are above {engineering principles|software best practices|plain fscking common sense}."


seems unfortunate....have you considered hiring some computer programers instead?

yawn
Monday, July 01, 2002

They are computer programmers damnit! 

the cluetrain
Monday, July 01, 2002

"They are computer programmers damnit! "

??? sorry, I must have misunderstood your previous post, I thought you said they were:

"a bunch of artists (hacks) that think they are above {engineering principles|software best practices|plain fscking common sense}."

yawn
Monday, July 01, 2002

I didn't claim to discover any bright idea.

I spent the last 20 years having software engineering rammed down my throat like the rest of the world.  Have you seen any real change in the failure rates?  I haven't.

Can you point me to any of the wonderful literature you mention promoting the art viewpoint, or are you just kneejerking at your conditioning?

Joe AA.
Monday, July 01, 2002

I haven't seen any real change because nobody fscking does it!  Except NASA & a few Govt. institutions.  And they have minimal failures. 

As far as doing your research for you:
type this in google:  programming as art versus science

Also see:
Mary Shaw "Abstraction and Codification in Software Engineering."

She's from Carnegie Mellon though -- ya know, the uni that brought us the SEI.

the cluetrain
Monday, July 01, 2002

Sorry for being harsh...  I'm a powerless developer that is suffering from mgt. AS I TYPE and I'm lashing out.

the cluetrain
Monday, July 01, 2002

No problem, I can take it.

I was really interested in individual thoughts.

Joe AA.
Monday, July 01, 2002

>How long are we going to wait for "Software Engineering"
>(see the purdy fireworks display) to save the world of
>software development?

From what? Is there some impending doom we all face if the amount of bugs doesn't decrease?

I don't think our industry has anymore problems than any other fledgling industry in the past. The first cars were certainly not the standard for quality. They broke down, they stunk, they were expensive, etc. But as time progressed people got better at bulding cars, competing with each other using quality as a competitive edge. Those that could build better cars faster than others won out.


As for your "software devleoper as an artist " argument, I partly agree. I would say that we are half and half. Equal parts right and left brain. We use left brain discipline to create software structures while using right brain creativity to come up with new ways to tackle problems. But this is no different from what an architect faces every day. They create structures using both left and right brain, building functional structures that also convey meaning.

Ian Stallings
Monday, July 01, 2002

Software development isn't an art. Right now, it's a craft - like woodworking. We may be quite creative in how we build our software, but the goal isn't to produce art for art's sake (well, not usually) but to make something that is practially useful.

The goal of the "software engineering" types is to take software out of the craft phase and into the industrial world, with repeatable processes, interchangable parts, and all that other good stuff. I think we'll get there eventually, but we probably need another 50-100 years.

Chris Tavares
Monday, July 01, 2002

Don't be a dumbass yawn.  We have people here that THINK they are artists.  They think they are good, but really they aren't.  They could use a dose of 'best practices' or whatever.  They could definitely use SOMETHING.  Surely you were clever enough to interpret my statement.  But if not....

the cluetrain
Monday, July 01, 2002

Of course, it may be an improvement for the end user if methods of industrialisation are applied to software development (or it may not; the end users inside clients of mine are notoriously uninterested in anything resembling more rigorous methodologies, lest it cramp their ability demand incoherant and condtradictary outcomes), but it won't be much fun for us craftsmen as we get turned into factory workers (with attendant shitty pay and conditions, with all our jobs shifted to the country prepared to impose the most horrible conditions on its citizens).

Rodger Donaldson
Monday, July 01, 2002

Joe AA.

Some questions for you, in regard to your question:

Q 1: What's the difference betweern VHDL and C?
Q 2: Why, after 6 months of development, can a team of 5 ASIC engineers write VHDL or Verilog, tape out, and then get an IC that "bloody nearly works"?
Q 3: Why does it take large software companies 10 years to write a windowing system that "bloody nearly works"?

Partial Answers:
1. VHDL and C.  Well syntax of course.  What they are describing obviously.  While they may seems worlds apart, in an abstract sense, they are not.  One describes hardware states, the other software states.  Yet they are both descriptive languages for "engineers" to create the executable machine.  C compiles more easily (usually), and is vastly more "simulateable" (sp?) which makes it that much more easy to to debug.  Is this a good thing or a disease?

2. Some thoughts come to mind:
. In ASIC land you get 1 chance to get it right, so you do it right the first time.
. Test coverage.  Test engineers in hardware land spend their career evaluating your design for 100% coverage.  Every state gets covered, every logical gate input stimulated, every propagated output tested for correct behavior - whether that state was designed in or not.  If your design isn't capable of 100% coverage, they'll persuade you to add in test busses and mutiplexers so that they can get coverage.  The tools for hardware test coverage are expensive, powerful and they work.  In an interesting twist, let's remember that these tools are written in 'C'.  How ironic.

3. Who knows.

I'll tell ya my impressions though:  writing bug ridden software in Seattle seems to be business as usual.  I thought that Redmond was a unique instance of not giving a damn, but its not.  Its a cultural phenom which seems to take refuge in the lame notion of "art and science" of computer programming.  Makes me sick.

It comes down to one fundamental, IMO:  If you know the correct behavior, and you know you have a bug, do you fix it?  Seems obvious, right?  But nobody wants to debug everyone wants to design.  Enough!

Nat Ersoz
Monday, July 01, 2002


> From what? Is there some impending doom we all face if the amount of bugs doesn't decrease?

Doom?  I hope not.  But in our increasingly litigious society where everyone's looking for a scapegoat, software companies are more and more becoming the focus of public's ire.  Referencing the recent calls for companies to be held accountable for bugs in the software they produce, these suggestions are only going to get louder.

To anyone that produces anything from freeware to expensive commercial applications.. can you imagine having to defend your company in court on a regular basis due to the incompetencies that we all know exist on the user level?

We all strive for defect-free software (at least I hope we do), but redefining the development process as an art as opposed to a science I fear would do more to mask a "hack" than justify a "genius".

And "cluetrain", everyone has management issues, but no one appreciates a hot-head that insults rather than discusses.  Perhaps you should take that "train" to get a "clue" about how to handle your present situation.

Marty Eichelman
Monday, July 01, 2002

Joe A.A. == Bella
the cluetrain == potty mouth

Hey Joel,

How about a minimum age requiremnt for these boards?
Or maybe a small quiz that would ensure posters really are developers...

Thanks,

Mr. Adult
Monday, July 01, 2002

Some real reasons software engineers are not artists:
1. I look goofy in a black turtleneck
2. My wife would leave me if I grew a pony tail.
3. I will not sell my nice suburban home and move into a downtown loft. Never.
4. No one will buy "programmer excriment in jar"
5. My code must look like something recognizable when it is finished.
6. Rich morons will not pay me to hang out with them because I am hip. I am not hip.
7. Most artists starve. Most programmers make more than the average US two income family.

It has been a long Monday, so I am treating this question with all the respect it deserves. Sorry if I offend.
To Nat: Have you done many ASIC's using HDL? In my experience it is not any easier than designing code. The cost of failure is higher so there is more reason to test. For most software, the cost of bugs is not as easy to account for.

Doug Withau
Monday, July 01, 2002

Sorry for offending you Mr. Adult.  Yes, I am a real life actual developer.  You think a non-programmer would be reading Mary Shaw?!!!

As for the f-bombs, well, I did use the linux zealot official spelling!  You should've heard how me & my boss were yelling at each other!  Ahhh, the fun of a startup.

the cluetrain
Monday, July 01, 2002

Hi Nat,

>Q1: VHDL vs C

Imagine that every single statement in your C program is running concurrently. Imagine the synchronization issues you would have to deal with.  Or that you have to think carefully about the capacitance as a result of wire lengths affecting rise and fall times of your individual bits. How would you handle it?

>Q 2: Why, after 6 months of development, can a team of 5 ASIC engineers write VHDL or Verilog, tape out, and then get an IC that "bloody nearly works"?

>. In ASIC land you get 1 chance to get it right, so you do it right the first time.

Nat, this is the main thing. You can expect the first metal fix to be free or at least expected and part of the cost. But after that it starts to get incredibly expensive. If you have to layout and remask a version, you're looking at $100,000-$500,000 each time you do that. There are almost always small errors, but often they can be fixed by changing the metal interconnect layers (a metal fix) which is not as expensive since wafers without the metal are set aside after each run for just this purpose. Still, your metal fix should be your last chance to get it right so you make sure you have fixed everything you can before doing this.

I have heard that a typical chip goes through 8 revisions to get it right. I don't think this is true any longer. The first two chips I designed got it right on the second try. The last chip I designed was perfect the first time.

How can we do this?

Well Nat knows part of the answer:

>Test coverage. Test engineers in hardware land spend their career evaluating your design for 100% coverage. Every state gets covered, every logical gate input stimulated, every propagated output tested for correct behavior - whether that state was designed in or not. If your design isn't capable of 100% coverage, they'll persuade you to add in test busses and mutiplexers so that they can get coverage. The tools for hardware test coverage are expensive, powerful and they work. In an interesting twist, let's remember that these tools are written in 'C'. How ironic.

Actually Nat, none of my chips had 100% coverage in simulation and verification. But it got enough done to see that it would work. I absolutely hate doing the simulations. It is a massively dreary pain in the ass. But it has to be done because if you screw it up the company goes under. These are expensive projects and failure is lethal to the health of the company and to your career.

I do have to write programs to generate and evaluate the testing and yes it's all done in C. But these are not complex programs -- it's the analysis to know how to do this that's the hard part.

When that chip comes out of the foundry, I need to know for a fact that any failures whatsoever are subtle timing errors that the model failed to be able to predict. Anything else, it's my responsibility to fix before the 'program' is 'compiled' (to silicon).

>3. Who knows.

Here's the other thing Nat, everybody who is successfully designing ASICs is the absolute top of the line. None of this 'no degree needed' stuff. You can't do it without a degree. Now maybe your degree is in physics or even english lit (though I haven't seen that) but the sort of people who have the brains to do this always make it to college one way or another because in their youth they craved the companionship of other thinking people. It's OK to have sloppy thinking and a "build it to see if it works" mentality when the cost of a build (compile) is a few cents or dollars but you can't have that when your cost of doing a compile runs in the hundreds of thousands of dollars. You have to know there are no errors in your code and be very surprised at the errors that do turn up. You certainly don't see errors in the silicon as a normal part of the process, you see that as physical evidence of incompetance.

Regarding art vs science, chip design is an art in which the highest and most meticulous levels of craftsmanship are required. Getting this right requires the mind and attitude of a scientist. Think of DaVinci -- he was a great artist because he was a great scientist. He was interested in getting it perfectly right the first time and that he did.

Ed the Millwright
Monday, July 01, 2002

We all hate buggy software.  So, why do we keep using it?  Usually, because alternatives are scarce, too expensive, or don't have the features we need.  Software, like any other product, has cost/benefit tradeoffs.  It costs more money to produce software with a reduced bug count.  More QA people, better management, experienced developers, etc.  These all cost money.

I think most any company can dramatically reduce bug count.  Just hire the top software person from NASA, let her hire who she wants to, allot a unlimited budget and a five year delivery date and accept that you're only going to get 1-2 LOC per day per developer.

Unfortunately, the market hasn't voted for these expenditures.  I want to buy to a car with the craftsmanship and features of a Mercedes and I only want to pay $12,000.  It's good to want things, but not always realistic.  A big-mac ain't going to be made with ground sirloin.

One of my favorite software development sayings is:

1.  Good (features, quality)
2.  Fast (delivery schedule)
3.  Cheap (cost to deliver)

Pick two, cause you can't have all three.

Bill Carlson
Monday, July 01, 2002

"We all hate buggy software. So, why do we keep using it? Usually, because alternatives are scarce, too expensive, or don't have the features we need. Software, like any other product, has cost/benefit tradeoffs. It costs more money to produce software with a reduced bug count. More QA people, better management, experienced developers, etc. These all cost money."

We all hate buggy software. So, why do we keep building it?

I'm the sole developer on a very large application that's been developed over the last 3 years.  It has no serious mission-critical crashing bugs; it does however have a few annoying bugs that rarely occur.  It probably even has some bugs that nobody has found.  It even has some dubious bits of design and some legacy code that does very little.

I hate bugs.  With a passion.  I feel it reflects badly on me to have them in there.  I also hate poor design.  I have to LIVE with my design decisions (I like a clean house too).

BUT...  I have about 100 other (more important) things to do.  I don't have time (money, etc) to redesign the poorly designed areas or fix the bugs that people don't come across. 

Wayne Venables
Tuesday, July 02, 2002

Engineering may not be the best model for software development. An engineer can build a bridge or chip without errors but can an engineer build a CRM system that works?  The problem is that no one knows exactly what is needed for CRM, or word processing.  There is no exact answer to many of the systems built today so it is not surprising that there are problems.

John McQuilling
Tuesday, July 02, 2002

Hi John,

I agree with you on the bridge but not the chips.

Chip development is aften done free-form nowadays, with features added in the middle of development because they seem cool to the developers or somebody at the time; this methodology if you can call it that it shares with software development but does not affect the error rate.

In other words, it is _not_ the usual situation that the feature set, specifications and functionality of an ASIC are spec'd out in advance and then developed according to some master plan that is not diverged from. The design tends to be more of an evolutionary process. It's just the level and intensity of testing and the quality of the developers that is different.

VLSI ASIC engineering is only 25 years old, whereas software development has been around for 60 years now. So ASIC engineering is even more of a black art or wild west scene than software engineering.

Ed the Millwright
Tuesday, July 02, 2002

I should also mention that another big difference is that most buggy software tends to be software that is being forced to run on a certain notorious OS platform known for its instability and complete lack of ability to hardwire exactly what sort of hardware the software is running on, or what other software might be running concurrently on the same processor, or even what versions of drivers can be relied upon being present.

When you design hardware, you have total control over everything. OK, sure, someone else designs your cell library, but it is genuinely error free and you don't have to worry about other chips suddenly appearing on your PC board unexpectedly and doing unexpected things.

The software side of things might be embedded systems programming where again you don't have to worry about viruses or the user suddenly downloading an incompatible graphics library into your toaster firmware so he can play pong while waiting for this bagels.

Because of the situation on the PC platform, I personally believe that the software quality problem is insolvable, given the current constraints (software must run on unspecified hardware running unknown and unknowable state of OS and other programs).

If hardware design had to live under the same conditions as PC software does, it would be full of errors too.

Ed the Millwright
Tuesday, July 02, 2002

"When you design hardware, you have total control over everything. "

Now *that's* funny.

Hardware Guy
Tuesday, July 02, 2002

"Ok... Lemme ask: How long are we going to wait for "Software Engineering" (see the purdy fireworks display) to save the world of software development?"

Maybe at around the same time that the requirements for software stop growing in scope at an amazing rate. I don't know about you, but the systems I'm working on are probably about 50 times as complex as they were even 10 years ago, and every time I start a project it contains a large proportion of new stuff.  I expect that at the point where people are happy for new software to do more or less the same as their old software, and at which it can be made up of simply plugging together a few dozen components then it will work as you wish.

There are few industries where we are asked to use new technologies to build a new bigger system,  with different requirements, all in reduced time every time something is made. I think the question should be how do we do as well as we do, not why is it so hard. (Although that in no way means we shouldn't try to do better still)

Also, people are willing to pay many millions of [insert local currency] for a bridge or something because they understand that absolute reliability is important, and they *expect* it to cost that much.  Software could be much more reliable but people are simply not willing to pay anything like the amount that it would cost to produce.

For example, I find windows to be very reliable in recent release, but there are still bugs. I'm sure that microsoft could improve it so that instead of coming across a bug once a month, you only come across a bug once every five years. But they'd need a whole team working on each part that currently takes one person then windows would cost $5000 per copy instead of $200 (not intended to be exact figures) and nobody would buy it. 

To sum up - people are getting the exact quality of software for which they are prepared to pay.

jb
Tuesday, July 02, 2002

"I'm the sole developer on a very large application "

Does anybody else feel this is a contradiction?

Just me (Sir to you)
Tuesday, July 02, 2002

"We all hate buggy software. So, why do we keep building it?"

Perhaps because usually the customer is not willing to pay for it to be defect free (or as near as as is humanly possible)? Is NASA code good? Yes, of course, but theirs is a situation where not only are they willing to pay for it to be so, they damn well have to - the costs of losing a satellite, or worse a manned mission, are huge (not just the cost of "replacements", also bad publicity and quite possibly a loss of budget as well). You only have to look at the discussion above about producing chips - the driver is cost, not whether the product 'should' be excellent quality.

Don't worry, I'm going off on one again. My gf doesn't understand why I complain that the doors in our rented flat are cheap or that there is not a light switch immediately inside the front door of our building. The reason those things are wrong is because someone decided that it was "good enough" and that they could make more a few pennies more by not picking up the extra costs. Its a sh*t attitude, and to be honest I'm pretty pig sick of it.

blech
Tuesday, July 02, 2002

-------------------------------------------------------------------------
Surely you were clever enough to interpret my statement. But if not....
-------------------------------------------------------------- cluetrain

Wow, cluetrain is even more inyourface than Bella.  I can't wait for them to have an argument.

Personally, I do agree with cluetrain.  There are far to many Prima Donna programmers who think they are producing clever code when really theyre creating unsupportable code.

Those of us who have to maintain all this 'art' have a very different view.

I would argue that programming art exists - take the 5k competition http://www.the5k.org/ .  I'd say that these entries are art.

This entry is amazing:

http://www.the5k.org/description.asp/entry_id=946

Its not very practical, though.  Monochrome, unintelligble listing, tiny window. 

Sadly, too much commercial code is the same.

Ged Byrne
Tuesday, July 02, 2002

--------------------------------------------------------------------------
The reason those things are wrong is because someone decided that it was "good enough" and that they could make more a few pennies more by not picking up the extra costs. Its a sh*t attitude, and to be honest I'm pretty pig sick of it.
----------------------------------------------------------------- blech

Blech is right, the problem isn't unique to software.  It happens whereever people try to do thing as cheaply as possible.

Its not just the deliberate cheapstake decisions, either.  Lack of quality control is there too.

Last weekend I had an expensive clean up bill because my flats builder's couldn't be bothered to fit together two pipes properly.

Ged Byrne
Tuesday, July 02, 2002

Ged - I don't mind the honest mistakes so much, though admittedly I haven't had to pay because someone failed to connect my pipes correctly (weren't they insured?). Anyone can make a mistake, it is the deliberate decisions to fsck someone else that I object to.

blech
Tuesday, July 02, 2002

Yes Ged, and I am tearing out the wall in one of the bath rooms now because the builder was too cheap to use concrete backer board and opted for plain drywall.

---

I didn't post the question to generate an argument based on stereotypes of artists vs engineers.  As a self-professed generalist, I have no problem stealing a technique from any profession as long as it helps me in mine.

I have many problems with "strict engineering" when it is applied to software.  For one, it has been stated many times that one of the goals of this approach has been to use the least able in place of the most able by building in (or assuming, pretending) that the real intelligence lies in the dogma of process and not the individuals.

The Ayn Rand quote, especially the second sentence, caught my eye because that is what I believe developers are expected to do.  The variety and the changing of requirements and so forth mentioned in the other posts seems to help justify that belief.

The "requirements" process in software engineering seems to be lacking.  I believe it is because requirements are supposed to be accepted as "givens", and are driven through the rest of the process.  One company I know of brags how something in a technical spec can be traced all the way back through various "design" documents directly to a requirement.  Their software product is extremely buggy, unstable, and composed of a large number of third party products.

XP also advocates this approach, with the stories being independent and used in negotiations for scope control. 

My basic problem with requirements as independent entities ignores the possibility of something I don't really have a name for... I have used the term "meta-requirement", meaning a requirement about the detail requirements themselves.  A requirement that when implemented, fully supports any number of individual, and previously thought independent, requirements - so much that the detail becomes redundant, unnecessary.

So enter the artist aspect - not as a stereotype of drunken paint slopping on canvas, a mindless hacker, or someone that has an unsupported image of excellence about themselves... but a person that can integrate seemingly unrelated aspects to create my meta-requirement.

Yes, I believe we make our own bugs.  I don't think it is due to cost-cutting measures or the willingness of what the "user" will pay.  In fact, I believe it is in the best long term interest of our industry to further cut both costs as well as bugs.

Both "real" art and "real" engineering have created works that have survived without peer for centurys.  Consider this in your replies, and please stop hammering the stereotypes.

BTW... how many of you know that during the building of the Empire State Building, the engineers were designing the next floor while the current one was being built.  So much for the argument that quality depends on a complete design up front.

Joe AA.
Tuesday, July 02, 2002

I think good software engineering is art. If we look at the things society considers to be art, such as paintings, music, drama and literary writing, we see that they are the products of distinctive talent. They are things that only certain talented people can do, and which the rest of society admires and values. The distinctive characteristic is that they are manifestations of restricted talent.

Using this criterion, I would argue that good software engineering is also art. There is art in assimilating a mass of competing requirements at the code level and designing a clean structure that accurately does all the things required of it and that can be easily modified when required. It's the difference between a million lines of code with multiple parallel implementations of the same concepts, and 1,000 lines of code that beautifully provides the same functionality in parameterised form. That's art AND software engineering.

A few folks interpret "art" as being mutually exclusive with quality, but I think it's the other way around. FWIW.

Hugh Wells
Tuesday, July 02, 2002

  ---
  "I'm the sole developer on a very large application "
  Does anybody else feel this is a contradiction?
  ---

Next time remind me to include "relatively" and "for a single person" when I say that!

Wayne Venables
Tuesday, July 02, 2002

"Using this criterion, I would argue that good software engineering is also art."

I'd extend that and say that "all good engineering is art".  Like a 30,000 transistor ARM core, is that not as elegant (or more so) than a well written network driver?

My bicycle, a Bianchi, IMO is a work of art.  Beautifully machined and symmetric, yet it pales in comparison to some other Italian bikes.  My commuter bike is ugly with fenders and grime.  Poor thing.

The point being that software engineering is not unique in this respect.  Less is always better when function is the same or improved.  Elegance is usually a metric of a job well done.

Nat Ersoz
Tuesday, July 02, 2002

Joe,

I agree with what you say.  Personally I prefer to think of myself as Craftsman rather than artist.

The problem I have with Artist is that implies something for its own sake - rather than fitness of purpose.

I personally think that the best code is the simplist code possible to do the job - an idea emphasised by XP.

Although I agree with most of the aims of Software Engineering, the one I disapprove of the most is the reduction of the coder to a manual labourer.

The goal seems to be a division of labour - with the skilled architect designing the system and the programmer just a labourer.

Ged Byrne
Tuesday, July 02, 2002

Art has never been produced for it's own sake.  Well, maybe by the pseudo-artists.

Music is also art.  I read a study once... about what other professions would be good at programming.  Musicans were at the top of the list, and the reason given was because they were capable of being creative within a structure.

Don't know if that is true... no one can be creative without some sort of structure.  Creativity requires constraints, otherwise it is just random motion.

Joe AA.
Friday, July 05, 2002

> Art has never been produced for it's own sake.

You're right.

Michaelangelo's David? Not Art.
Van Gogh's Starry Night? Not Art.
Da Vinci's Last Supper? Not Art.
Botticelli's Birt of Venus? Not Art.

Coke bottle? Art.
Empire State Building? Art.
MS Windows? Art.
The Great Pyramid of Egypt? Art.

Art Kreitik
Friday, July 05, 2002

Artists create art for themselves, for their sake, not for the sake of the "product".

Much like good engineers.

Lousy artists and engineers slap something together primarily for the paycheck.

Joe AA.
Saturday, July 06, 2002

*  Recent Topics

*  Fog Creek Home