Computer Programming as Stochastic Art

Apparently the ancient philosophers used the word art to mean a body of knowledge about a subject that enables the artist to achieve a particular result. Art was broadly applicable to most any organized practice that people might undertake—what today we rather call vocations or professions.

But the ancient philosophers had a nagging problem. While they could easily criticize a shoemaker for failing to successfully create a pair of shoes as being insufficiently skilled and knowledgeable about their art, they had a hard time convicting a doctor of being insufficiently knowledgeable of medicine simply because their patient died. Thus a debate ensued about how to judge an artist’s skill based on some other criteria than the results of their practice.

The ancient’s coined the term, stochastic art to differentiate those arts in which the knowledge and skill of the practitioner could not be measured simply by the results of their work. They were particularly interested in this idea as it relates to the art of rhetoric and oratory (a form with which some Greeks had a famous obsession).

Stochastic means to “guess at.” But in this context it means, “to aim.” The point being that the aim of the artist is as important as the results, even if they miss their target. And that significant credit can be given to the methods they use, regardless of those results.

Aristotle himself used a lucid example when he said that the product of medicine is not health, but the practices that move the patient as far towards health as practical for the circumstances. He went on to say “It is possible to give excellent treatment even to those who can never enjoy sound health.” (Rhetoric 1355b)

So now we’ve got a framework in which we can categorize art forms. Anecdotally it appears that productive artists like blacksmiths and cobblers can be more easily judged based on the product of their work, while problem solvers like mechanics, doctors and politicians need some latitude to recognize their skill and knowledge as distinct from immediate results. One can recognize an excellent oncologist, even if the majority of their patients tend to die.

Thus the light bulb that illuminates my dim wit, and says computer programming, and probably other specializations of IT, may fall into the category of stochastic art. Keys to the distinction are complexity, problem solving, creativity, and an artist-subject relationship atop a substrate of deeply technical subject matter. This perspective provides a possible out from the dilemma of why writing software does not fit well into the model of building a bridge or a sky-scraper. It may also be a useful tool to help explain other problems with IT that we break our pick on every day.

Doctors, like programmers, are people with deep technical knowledge who rely on their experience in a search for specific solutions to problems. They’re constantly looking for solutions in an ever-changing environment. To make things more challenging for the programmer, their art is probably less episodic than that of the doctor. The programmer must deal with the code they write during spurts of creativity and action from the day they write that code forward. This perspective, for example, provides insight into the central tenant of refactoring in agile methods. (As an aside, note that we're not talking about Stochastic Programming here--that's a different animal).

Additionally, some people believe that the majority of IT projects are failures. Typically, when they survey the beneficiaries of a project, those beneficiaries report to be dissatisfied with the results. While the IT professional might have used the proper methods, they may have missed the aim for a variety of reasons external to their control. Just as most oncologists’ patients die, most IT professionals' projects fail?

This isn’t a mea culpa for the programming community’s failures. In Scientific Failure, James Allen writes that: “failure..led to revisions of the conception of an art itself and the associated notions of artistic knowledge and expertise.” What can we learn from looking at IT from the perspective of stochastic arts and analogues like medicine rather than traditional engineering arts?

For example consider the problem of project management in software development. Imagine if a project manager developed gantt charts and task lists for a team of medical professionals attempting to diagnose and treat a patient with a degenerative neurological disorder. Like most software projects the problem solving, testing, diagnostic attempts, treatments, and the patient themselves simply may not cooperate with the best laid plan. And in the case of something like Alzheimer’s, the project is probably destined for failure if you use the obvious success criteria.

But medicine isn’t all ad-hoc. Methodological techniques and protocols exist in medicine that attempt to provide some deterministic quality to the practice. For example, how do doctors put a schedule on their treatments? There’s probably a lot to gain from the perspective of computer programming as a stochastic art. We should look for examples of stochastic arts and non-stochastic arts and compare and contrast them with computer programming. We may learn from that exercise.