The Software Artists: Index of Links to All Sections

Explanation
Introduction

The Value of Software
Citations for Part One

The Software Artists: Citations for Part One

Many of the ideas in this paper were first presented at the Austin
Workshop on Test Automation in early 2007. The substance of
the talks appeared on the author's blog shortly afterward:
http://chrismcmahonsblog.blogspot.com/2007/01/craft-and- discipline-larks-tongues-in.html

Most of the New Criticism and Structuralist citations are from
Wikipedia, except:
Child Jr., William C. 2000 Monroe Beardsley's Three Criteria for
Aesthetic Value: A Neglected Resource in the Evaluation of
Recent Music. Journal of Aesthetic Education, Vol 34, No. 2
(Summer 2000), pp 49-63 doi:10.2307/3333576
The author did not know that unity/variety/intensity had been first
presented in music criticism until reading this article.

The author also referred to
Adams, Hazard, Searle, Leroy (eds.) 1986 Critical Theory Since
1965 University Presses of Florida/Florida State University Press
for background information.

Bruce Schneier on “security theater”:
http://www.schneier.com/blog/archives/2006/08/terrorism_secur. html

The Software Artists: The Value of Software

Previous: The Software Artists: Explanation
Previous: The Software Artists: Introduction

Philosophy of Art and the Value of Software

Manufactured goods generally have a clear relationship between
cost, price, and value. In software, as in art, the value of the work
is more often completely unrelated to cost and price. Operating
systems provide a great example: the Windows audience for the
most part must use Windows regardless of cost or price. The
Mac OSX audience generally chooses to use OSX regardless of
price, and often explicitly because of the aesthetic experience of
using OSX. Linux has no cost at all, and a price that varies
wildly, and it also has a dedicated audience.

The value of software, like the value of an artistic performance,
lies in the ability of the software to attract and keep an audience.
The software industry would benefit immensely by turning the
tools of artistic criticism on software.

The 20th century in particular saw a great proliferation of critical
theory of artistic work. Among the most important ideas were
The New Criticism and Structuralism. Both provide fine tools
for evaluating software.


The New Criticism: The Intentional Fallacy and Aesthetic Value

The New Criticism was the most important school of literary
criticism in the middle of the 20th century. An essay this length
can touch only lightly on some key ideas of New Criticism, but
those ideas turn out to be quite valuable.

The New Critics believe that once the authors finish their works,
they disappear from the milieu in which the work exists. New
Critics do not involve themselves in what the author intended to
create; they concern themselves only with the work as it exists.
This principle is called the “Intentional Fallacy”: what the author
intended has no part in the value of the author's work.

Creating software can be seen in a similar light. Once the
software is released, the team that created it cannot control how
the software is used, nor who uses it, nor what it is used for. The
value of the software must lie in the software itself and in how it
is used, not in how it was created or in what it was intended to do.

The most important tool of the New Critics is a technique called
“close reading”. From Wikipedia: “close reading describes the
careful, sustained interpretation of a brief passage of text. Such a
reading places great emphasis on the particular over the general,
paying close attention to individual words, syntax, and the order
in which sentences and ideas unfold as they are read.”

Creating software has its own kinds of close reading: code
review, unit tests, and feature tests are all ways in which software
creators emphasize the particular over the general. But one of the
most important results of close reading, and one of the most
important aspects of value to New Critics, is to identify and
examine the works for ambiguity. These ambiguities are
examined for their value: some kinds of ambiguity add to the
value of the work; some kinds of ambiguity detract from the
value of the work.

Software whose ambiguous features allow the user to do more
than the developers intended will be more valuable-- think of a
wiki. Software whose ambiguous features stop the user in his
tracks has much less value-- think of the Windows Vista security
regimen.

Aesthetic Value: Unity, Complexity, Intensity

Monroe Beardsley, who wrote “The Intentional Fallacy” along
with William K. Wimsatt, also proposed a way to measure the
value of a particular work. Beardsley states that the value of the
work resides in three criteria: unity, variety, and intensity.
Applying these criteria to software is an interesting exercise.
Software may be unified if all of its features support a central
activity or theme. Software may have variety if the features cover
a wide range of activity. Software may be intense if using the
software is a compelling experience.

Periodically examining a software project throughout the
development process using these criteria is a fascinating exercise.

Structuralism: Signs and Myths

Structuralism became popular later in the 20th century. Where
New Criticism seeks to examine particular works disconnected
from intent or affect, Structuralism is rooted in linguistics and
anthropology, and seeks to examine works in the context of their
language and of their culture.

Two aspects of Structuralism are of particular interest: the idea
that linguistic signs can be decomposed into the signifier and the
signified; and that works can have deep structures that reflect
cultural values that can be represented as myths.

Signs: Signifier and Signified

A linguistic sign is a speech act: a word, a sentence, a poem, a
book. It is not at all unreasonable to treat the use of a software
feature or a software user interface as a sign.

The signifier is the “sound pattern” of the sign. It is what
happens in the physical act of speaking, or in the personal act of
reciting to ourselves. Furthermore, signifiers are the tokens by
which people communicate. Signifiers are what people send each
other as they participate in culture.

The signified is the “concept or meaning” of the signifier. The
signified is the true act or true feeling or
physical/emotional/apprehended manifestation of the signifier.
With the ability to separate signifier and signified, the
Structuralists look for common deep elements and mythological
underpinnings of artistic and cultural works.
The value of any particular work, then, can be evaluated in
several ways. A work might have value to a Structuralist if:

• Signs are rich and easily available
• Signifiers in the work are rich and pleasant
• Signified are deep and clearly delineated by their
• The work reflects a rich understanding of the cultural mythology and milieu
  

Exercise: New Critical and Structuralist Evaluation of Browser Behavior

New Critics contribute the idea of close reading in order to
evaluate unity, variety, and complexity of a work, looking for
ambiguity in the service of a rich aesthetic experience.

Structuralists contribute the ability to separate signifier and
signified within a work, in order to evaluate the richness of both
the experience of the work itself and the extent to which the work
relates cultural mythology, either that of the work itself or that of
the consumer of the work.

As a thought experiment, use these tools to measure the value of
this behavior:

When Internet Explorer opens a web page that contains MPEG3
files (for instance
http://www.drummingstyles.com/Genres/Latin/Bossa-
Nova/index.html), it by default prevents the user from loading the
page, and pops up a warning message that reads

(IE6 and IE7) Do you want to allow software such as
ActiveX controls and plugins to run?

(IE6) A script is accessing some software (an ActiveX
control) on this page which has been marked safe for scripting.
Do you want to allow this?

(IE7) This website wants to run the following add-on:
'Windows Media Player' from 'Microsoft Corporation'. If you
trust the website and the add-on and want to allow it to run,
click here...

A New Critic can use close reading on this behavior to see if it
exposes any ambiguities. If those ambiguities contribute to the
unity, intensity, and variety of the experience, then the behavior is
valuable.

Since the only executable files on the page are mp3, the false
reference to ActiveX sends the reader down a false path. Since
there is no explanation for why an mp3 is considered to be
ActiveX, this falseness only detracts from both the unity and the
intensity of the experience.

Furthermore, since the software requires validation of behavior
that the reader requested anyway (the false “ActiveX control” is
in fact “safe for scripting”) this behavior can only detract from
the whole point of the work, which is to play the mp3 file while
reading the text of the page.

So a close reading of the the behavior in question in a New
Critical sense shows that the software reports false information.
Although the behavior could be construed as adding variety, it
does so for no good reason, and prevents the experience of the
work itself, which is to play the mp3 files while reading the page.

A Structuralist would have a different interpretation. The
references to ActiveX are a signifier, but it is unclear exactly what
is being signified, since the obvious signified (a real ActiveX
control) does not actually exist.

The Structuralist finds a clue in IE7, where under some
circumstances, when loading a page with mp3 files, warns “This
website wants to run the following add-on: 'Windows Media
Player' from 'Microsoft Corporation'. If you trust the website and
the add-on and want to allow it to run, click here...”

Microsoft itself is concerned about security, or at least about the
appearance of security. Perhaps the false warnings are intended
to warn about the possible insecurity of the Microsoft Windows
Media Player itself.

Looking at the wider culture, everywhere from airports to banks
to offices, there is a demonstrable trend toward what Bruce
Schneier calls “security theater”. Security theater is
“countermeasures that provide the feeling of security while doing
little or nothing to actually improve security”.

A Structuralist will see that the culture that produced this work
values “security theater” while providing only the appearance of
security, so the Structuralist will concede a certain value to this
Internet Explorer behavior that a New Critic would not.

Citations for part one

The Software Artists: Introduction

The people who create software are not factory workers. Nor are they engineers, in the sense that engineering is the “practical application of the knowledge of pure sciences, as physics or chemistry”. But the software industry continues to treat software workers as if they were factory workers or construction workers. The software industry also attempts to value software as if it were a manufactured product.

But making software is a fundamentally creative process, more similar to performance than to manufacturing. Like art and music, software has an audience that is involved in a personal way with the software. And the people who create software are much more like performers than they are like construction workers.

If it is true that software is much more like art than it is like manufacturing, then the tools of artistic criticism should be useful for evaluating software.

It should also be possible to apply successful approaches to art or music pedagogy to software pedagogy.

Furthermore, it should be possible to manage software projects in the same way that artists manage performances, with better results than if the software projects were managed like manufacturing or engineering projects.

The Software Artists: Explanation

I wrote a paper some time ago to submit to the Conference of the Association for Software Testing, but the paper was not accepted for the program. I'm on the waiting list if another presenter drops out, which seems unlikely at this point.

I think it is likely that my paper was not accepted at CAST was because it is somewhat similar to a presentation from Jonathan Kohl and Michael Bolton, two of the best testers in the universe. I intend to publish my paper here on my blog in the hopes that Jonathan and Michael and other Software Artists will have access to as much relevant information as possible to support their position.

I think that one enormous reason that few people take software-as-artistic-practice seriously is because of a perceived lack of practical application: manufacturing and engineering provide venerable examples of measurement tools, education curricula, and market strategy-- assuming that you believe that software is an engineered and manufactured product. Those of us who believe that software is an artistic process have failed to provide compelling alternatives to the tools provided by engineering and manufacturing.

I set out to start to remedy that situation with this paper.

It is a long piece, so I'll publish it in several sections in the coming days, as I have time to get it right and looking good. I have extensive references also. My plan is to publish references as separate blog posts after each section, so that people who don't care can skip them and people who do care can relate them to recent posts.

technical debt as impedance mismatch

My colleague Matt Heusser will be hosting a peer conference on "technical debt" later in the summer. I've been thinking about the subject and realized that technical debt could be interpreted as a kind of impedance mismatch. Impedance mismatch happens in acoustics, electric current, and many other places. Here are a couple of examples that everyone will understand:

trying to fill a swimming pool with an eye dropper

trying to get a drop of water from a firehose

I can think of two software examples from my own career, one involving tools, the other involving skill.

An application I was testing the other day has two javascript prompts in a row. Selenium correctly recognized and dismissed the first prompt, but it is not able to see or manipulate the second one. As a result, I have an unfinished automated test, and technical debt in the form of selenium hacking, manual testing, and future test maintenance. This is the eyedropper-swimming-pool example: no matter how much effort I expend, there is no way I can overcome the nature of the problem at hand. I'm forced to improve my tools in order to overcome technical debt.

In my career I have been a tester on two different COBOL systems. One was very nicely designed and maintained, the other was a total nightmare. The developers of the nightmare system were very poor coders. COBOL makes it easy to do dumb things, and the codebase was full of dumb things from people who didn't know any better. This is the water-drop-from-a-firehose problem: gross efforts were accepted when fine manipulation was required. The developers have to improve their skills in order to overcome technical debt.

If this really is a valid comparison, it might even be measurable in the way that electric current and sound pressure levels are measurable. If not, it is still worth noting that having the appropriate tools and the appropriate level of skill in the project team will likely minimize technical debt.

advice on a selenium problem?

I thought I'd mention this here. If anyone has a theory, please leave a comment or find me somewhere...

I'm using Selenium to drive a Javascript WYSIWYG editor. I type some text into a largish textarea; save the page; open the page again in the editor.

Upon doing this, IE7 can properly read and parse the contents of the textarea, but Firefox thinks the textarea is empty.

I can set up an environment to reproduce this for an interested party.

my lecture at Fort Lewis College

Boulder Ruby Group: telecommute panel Nov 14

I'll be part of a panel on distributed agile working/telecommuting/remote working tomorrow evening Nov 14.

If you can get to Boulder, stop in. If you're interested in following along, there'll be an IRC channel running. (probably freenode #socialtext, unless we change our minds.)

Also, I have a wiki dedicated to the topic. For tomorrow evening the wiki will be totally public. I intend for the wiki to stick around as a repository of information about working in distributed teams. Leave a comment or send an email if you'd like access to that wiki.

test design economy

The other day Jeff Fry sent me an IM out of nowhere and in the course of the conversation asked me what I was doing these days.

I blithely answered "not so much coding, more test design". Which was really too short an answer, but there's IM for ya.

In a nutshell, Socialtext has a really nice Selenium-based automation framework, and recently I've been attacking the backlog of creating automation for fixed bugs. When I'm doing manual (Exploratory) testing on these code changes, I'm willing to spend time investigating odd combinations of things, multiple recurrences of things, all sorts of unusual experiments to find where exactly the boundaries of the functions lie.

But automated tests are expensive: they are expensive to create, and they are expensive to run. So when writing the automated regression tests, I'm trying to minimize the number of test steps while maximizing the coverage of the code in question.

Here's an example:
| type_ok | email_page_subject | Fw: Fwd: Re: Email subject %%start_time%% |

We needed to test that email forwarded or replied to, on the same subject, would appear on a single wiki page. Manually, I tested every combination of "Fwd:", "Fw:", "Re:", after investigating all the permutations that various email clients might employ.

But when I wrote the automated test, I chose the most pathological case that I knew would succeed, in order to minimize run time and maximize the chance that the test would catch a regression problem.

Automated GUI testing is too expensive to cover all the cases that a human being can conceive. There is a craft and a discipline involved in creating automated tests that are both effective and economical.

I am very much enjoying exercising that craft and discipline.