Software Is Art

Something is terribly wrong with the way that we try to make large pieces of software. For several years now, I have had the nagging suspicion that we are trying to imitate entirely the wrong crowd of people. We keep trying to act like engineers. We, software developers, are simply not engineers at all.

No repeatability, see. Building software is not at all like building bridges, thousands of which have been built before, in every conceivable situation, for a huge variety of purposes, using inumerable kinds of materials. For us, every creative act is one which explores a new medium, new materials, new dimensions. Perhaps, a few hundred years from now, software building will become repeatable, predictable, and therefore "engineerable".

Now, I am not trying to deny the creative part of engineering. Nor am I decrying the many good practices we can learn from the engineering disciplines. Nor do I wish to offend old friends, many of whom are fine engineers. But we are not, and cannot be doing, engineering.

What we do is much closer akin to art. This constantly striving to be something we are not lies at the heart of many of the woes and frustrations of the software development process - the failed methodologies, the unused notations and the ignored theories.

So, apart from noisily proclaiming SoftwareIsArt, is there somewhere more fruitful we can look for analogous modes of working? Yes! Theatre, and especially that part of theatre that makes movies. They, too, work with a highly technical process involving large teams of people and sometimes huge amounts of money, need widely differing sets of skills, and start from a poorly-understood "specification" to achieve an end-product that is a marvelous mixture of art and science.

Now think how many movie-productions are late and over-budget. How many are box-office flops, despite all the "right" ingredients. How many end up making just another bit of candy-floss.

When I look at and read about software projects that have been very successful, it seems to me that they were almost always organized more like movie-production teams than like an engineering design/production team.

I think it is time to "come out of the closet", and confess that we are closer to being artists than we are to being engineers.

Some of this is not what I started out trying to say. Part of why I think SoftwareIsArt has to do with starting, as a painter does, before a blank canvas, familiar tools and palette to hand, striving to translate some clean and beautiful conception held clearly in mind's eye, through an imperfect medium, into something lovely desired by others (who hopefully pay you for it!). Somehow, this seems far different from the path that burst out above...

It also seems to me that ExtremeProgramming is a recognition of this same idea - just take a look at ExtremeRoles, and try and relate them to analogous roles in movie-making...

You know, we keep looking for another field that captures what developing software is really like... but I think developing software is really like developing software, and not anything else. It is something new, it is itself. Decades from now, something else will be likened to writing software. However, I also have tried to find what software is like, and wrote SoftwareDevelopmentAsCommunityPoetryWriting. Which I thought was pretty close, until I more recently thought up SoftwareAsRockClimbing, more generally put as SoftwareDevelopmentAsaCooperativeGame, but rock climbing has something special about it. So I agree in large part with this page, saying SoftwareIsArt more than Software Is Engineering, and mark the difference with those pointers to other pages. -- AlistairCockburn

Yes, Software is really just like Software. But! People (lots of them) in the game keep looking to the engineering disciplines for helpful methods, processes, structures.

See DisciplineEnvy.

Agreed. As one professor countered, when I likened programming to art, "but then how can we standardize tests of programming, or set up Advance Placement tests?". And so some group of us try to pull in other similies to highlight the non-engineering aspects of software development, while others keep looking to the most precise activities, to help force it to become more precise. -- AlistairCockburn

Software is not art, but craft. Art appeals to the emotions.

Much software can be engineered. Most software has been written before.

In his book AccidentalEmpires, BobCringely floated the idea of a software production model along the lines of a Hollywood Film Studio. Developers get together for only one release. If the release is successful and people want it, the group can be reformed for release 2 "the next generation"...

He thinks that having "one in twenty startups failing" is scaring too many people away from developing their new ideas.

Maybe this business model would reduce the urge that some people must have to produce upgrades that customers don't really want (aka Landfill Releases).

Does it make sense to have SoftwareAsFilmMaking?

(Maybe this explains some of the "cute" Help->About scrolling dialogue boxes around.)

--

KenAuer hosted a workshop on software development as a studio discipline at Oopsla98. See http://www.rolemodelsoft.com/OOPSLA98/studio/index.htm.

I have very strong feelings about this page, but the feelings are muddled. On the one hand, I like being creative and I tend to think that many people get into software development because it is a creative discipline. On the other hand, I am sure that if we do not see the artistic model as a problem, the rest of the world will.

In the artistic model, the artist has a vision and goes for it. There are two general ways to go... one is to secure sponsorship and place your vision up for negotiation; the other is to go it alone, uncompromised and possibly doomed. Artists often consider it a victory when they are able to get their vision across, even if it is at the expense of their sponsor's vision. Can developers afford that reputation? I don't think they can in general.

There are many cases of strong-willed people who thwart all obstacles to bring their vision to life, using clients as a means to an end and caring little for them. The attitude is "here is a person with money who will let me fulfil my vision." If the visions are coincident or the artist is persuasive, this approach can work, but it often becomes a loss for the customer. We can appreciate films and paintings, but someone had to live in FallingWater; likewise, people have to use software.

Some software does have a wow factor. Games are like that, but much other software is deeply utilitarian. Sponsors don't want developers to pursue an idiosyncratic vision, knock their socks off, or compete for the attention of other people. They just want software that is unintrusive and allows them to work better. And, you know, if somehow they found a way to do their work better without software, many of them wouldn't miss a moment's sleep. If SoftwareIsArt, we are our own primary audience. I don't think that is too bad, unless we forget it. I think that engineers must have the same sense of appreciation for their work.

-- MichaelFeathers

I think that, before we can judge whether SoftwareIsArt, we have to know what "art" is, and I suspect that the modern view of art - something existing for its own sake, lying out of the ordinary world, intelligible only to art scene insiders - is not helpful for mining whatever may be useful from this classification.

The Scholastic formulation conceives art as an intellectual virtue, an operative (as opposed to speculative) habit of right reasoning about something to be made. Now, if you ask me whether creating good software involves right reasoning about something to be made, I will answer yes a lot faster than if you ask me whether good software is a work of art.

With this more robust notion of art - rather than something like "an object created to be looked at and reacted to" - I think I can get something out of thinking about art in relation to creating software.

I wonder, too, about the usefulness of distinguishing art from craft, or artist from artisan. I think this is a relatively recent distinction with little value for understanding software. The Scholastic distinction is between the fine arts, whose end is the beautiful ("that which, being seen, pleases"), and the other arts, whose end is service to man. Can I say that SoftwareIsArt but BeautyAintMyBusinessNoSir?

-- TomKreitzberg

A bridge or a circuit board can be represented with precision in another language: math. But code has only one precise representation, itself. (UML is imprecise, often fuzzy.) I think this is parallel to art: a painting really can't be described, it must be seen as it is.

-- BradWilliams

Software is regarded by many as a science, art, trade, and craft all in one.

This quote from CharlesSimonyi provides a good summary:

"The knowledge of the best algorithms is the science, and the imaging of the structure is the art. The details of algorithms, writing efficient lines of code to implement transformations on those structures, is the trade aspect of programming. Technically, this is called maintaining the invariances in the structures. Writing the code to maintain invariances is a relatively simple progression of craftsmanship, but it requires a lot of care and discipline."

-- MichaelLeach

I just want to say that I think that Engineering Is Art. A good phrase I learned at one job I had (where I worked as a manufacturing engineer) is that if we keep doing things the way we did yesterday, we will only be as good as we were yesterday. This applies for engineering and it applies for software. You shouldn't reinvent the wheel in either software or engineering. You should see how things have been done and learn from it. You should have a toolkit of experience available in either one that you use ("this worked really well last time when I did this...") and maybe make carbon copies of tidbits in order to speed up a new project that's similar to an older one. This all applies for both software and engineering.

Engineering involves understanding the world around you and manipulating it to accomplish a purpose. You have to know more than just the common sense. You have to know theories and laws and design systems. Software is the same thing but the world you are in is all man made: the computer. You have to know your programming language's traits, strengths, and weaknesses. You have to know your hardware. You have to know mathematical theories, laws, and algorithms. This math came from the real world where math is a universal language.

I know I'm not a real programmer. I'm not even a full engineer yet (nearly graduated). I'm also a designer. Maybe having all these experiences reduces my abilities and biases me. They are all rooted in the same foundation from my experience. It's problem solving and it is art.

-- HeatherRisedorph?

Just like an artist, we can try to visualize the end result in our mind before even touching the paper (or PC). Design is like the the light outlines that are drawn at first to get the basic objects in proper perspective. Lines of code are like strokes of a brush, every drawn with care and precision. Watching things work is like stepping back and having a contented look at the image created.

-- Sanjay

It was said earlier, "Software is not art, but craft. Art appeals to the emotions."

I'd say that software appeals to the emotions as well. Surely all of us here can say that they've seen software that makes them want to retch; while, alternatively, on occasion we run across code that is so elegant and beautiful that it causes us inspiration. Code isn't always just about the results it produces; in many respects, it's also about the process, and is very close to writing and drawing. -- JasonLaPorte

CategorySubjectivityAndRelativism