Art Craft Engineering Science

I have another taxonomy of creative disciplines (as opposed to ArtCraftSoftScienceHardScience). There are arts, crafts, engineering, and sciences.

An art is a discipline that is bent on creating something with aesthetic value only. Little of what we call "art" is used for anything but our own minds. Making origami is an art; its job is just to sit there looking pretty. A craft is a way to create a unique object (rather than a mass produced one) where the criteria for success are qualitative. Making a rope bridge is a craft, even though there are obvious weight requirements, because you don't really quantify those requirements. An engineering task is a way to create a unique object, or a template of objects (such as a plan for a new mass-produced car) where the requirements are largely quantitative: making a box that moves down a street isn't enough; it has to reach 0-60 in this many seconds, get that many miles per gallon, hold some quantity of people/cargo, cost less than the market value, etc.. Often, engineering requires building prototypes; building those prototypes is usually a craft. Building a bridge for traffic is an engineering task because the numbers are predicted using science, as opposed to experiential skill.

Finally, a science is a way to create pure thoughts that influence our engineering. Bridge-builders, for instance, consume laws of Newtonian mechanics from science so that they can predict the quantitative performance of a bridge before they build it. Programming is rarely a science, sometimes engineering, but usually a craft. No example of programming-as-science comes to mind, but there is certainly a lot of science going into programming (codify natural laws found by science, and you have a simulator). Programming is an engineering discipline when the goal is not to add new functionality, but to make existing functionality work to certain quantitative goals. A lot of OS design and database work, for instance, is engineering. Making new functionality is usually a craft, where the result isn't getting something to work at such-and-such a speed but getting something to work at all.

Programming is also an art, especially when the programmer is programming for fun, often times I'll make the code as pretty and elegant as possible, despite the fact that few would ever see or appreciate it. I get a bit of joy both from writing beautiful code, and a bit from thinking that some other programmer may enjoy reading it later on in maintainence. Often times the purpose of the program is secondary to act of writing the code and playing with patterns in interesting ways.

This seems to me to skip over the whole area of ApplicationDevelopment - surely this involves creating new functionality. Currently ApplicationDevelopment is somewhere on a spectrum between craft and engineering - hopefully moving in the direction of engineering. BradCox has described how a similar evolution in the technique of rifle-making laid the foundations of modern mass production. This does not mean that the aesthetic has no role in programming however, just as a bridge must not only be functional, but also can (should?) be attractive as well. These beliefs underlie much of my work on FlowBasedProgramming. --PaulMorrison
Isn't "to sit there looking pretty" a qualitative requirement? I think by the above definitions art is a craft. (But then I also think the distinction between art and craft isn't nearly as important as a lot of other people seem to think.) I would distinguish them along the lines of "art is a discipline for making something to be apprehended," while "craft is a discipline for making something to be used." -- TomKreitzberg

For me: Art -- Engineering -- Science share a common social process wherein something is produced, judged, and possibly rejected. However I would argue that Engineering takes in what Science has produced (ideas that should work) and produces artifacts. Scientists may make things, but these are tools leading to some idea that can be published, reviewed, shredded, diced, sliced, and (if it works) fitted into a growing web of TextBookScience?.

The other continuum (from where I'm sitting) is: Art -- Science -- Humor. ArthurKoestler? (spelling?) suggested that TheActOfCreation? was similar in each of these. He called it Bisociation -- the perception of two separate ways of thinking as sharing a common point. In art the connection is made slowly and we experience it as poetic and moving. In humor the connection is made quickly and we laugh. In between is the slowly dawning and then sudden AhHa experience of the scientist recognizing that two quite distinct matrices are really one. For example, Newton seeing that an apple and the moon as following a universal law rather than being in different spheres and following different rules.

-- DickBotting

The relationship between Science and Engineering is really not one of continuum. DavidParnas has an excellent paper called SoftwareEngineeringProgrammesAreNotComputerScienceProgrammes? in which he discusses the differences between a science education and an engineering education. Specifically, "scientists learn science plus the scientific methods needed to extend science" while "engineers learn science plus the methods needed to apply science." Looking at the activities of, say, physicists and electrical engineers seems to confirm this characterization. Physics underlies the work of both, and both use the same base knowledge, but the depth, breadth and use of the same science is radically different.


NateEdwards used to quote the saying "Scientists discover what is; engineers build what never was"! Comments? --PaulMorrison

EditText of this page (last edited August 23, 2010) or FindPage with title or text search