Sudoscience

Usefulness: a real metric?

Table of Contents

NB: I updated this post to reflect some comments made by concerned readers. In the process, it was also restructured, and some of the more dubious claims removed.

1. Review

If you didn't read my previous blog post, you should do that. It introduces some of the ideas that will be expanded upon here. The primary takeaway of that introductory piece is the identification of two ways of thinking about contemporary software development as a discipline. They are relatively ordinary: is it a science or an art?

The question may not excite you: who cares, after all, whether what one does is truly a science?1 The problem as I see it is, on the one hand, the continuous disparagement of art (by which I mean chiefly the "fine arts") in our culture; while still freely borrowing the language of the latter, especially in the service of describing the psychological, cultural and broadly affective components of doing the job of a software developer. On the other, people apply the label of "science" to things that need the stamp of a legitimacy they feel is wanting.2

Why do we feel that science makes serious while art is merely a decorative but ultimately insufficient mark of significance? Is it only a cynical endorsement of large enterprises, and the principles of "free market" capitalism? The sincere and high-minded devotion of a logical thinker? Or is it the embittered attitude of people who have failed to make their way as artists, and have turned to more remunerative tasks in order to pay rent?

These questions are too weighty to be given full consideration here. Instead, I will examine in a little more depth a couple of examples of the habit/practice mentioned above, and attempt to link this phenonmenon to our hazy understanding of the demarcation between art and science.

I proposed that art is "merely decorative," perhaps leading one to believe that I was referring exclusively to "fine art." I am not. This label is applicable to that other definition of "art," as a kind of handiwork, or craftsmanship, the product of an artisan. Of course, this has been the definition of art for far longer (thousands of years) than our modern, all-too-modern understanding. Yet this same understanding of art mires we workers of the software world in an unpleasant morass.

2. An instructive reference

For those things we do esteem vain, which are either false or frivolous, those which either have no truth or no use…

  • Francis Bacon

In the service of this continuing study of software development qua scientific/artistic practice, who better to lead us down the garden path than the inventor of science, Sir Francis Bacon? "But surely you are not suggesting that science was — invented?" Science is that pure, crystalline, near-perfect attainment of a sharpened human mind, a set of principles inherent to nature that can be revealed:—but invented? Surely not.

Copious time and energy and sheets of paper have been devoted to the matter of defining an idealistic kind of science, one that respects sufficiently the faith of its adherents. What I propose is that this is not the kind of science that software development could ever be, if it even wants to try. That is to say: there is a second, pragmatic kind of scientific work, one that is exclusively concerned with results that can be seen, tabulated, and reported upon.

The ability to venture into the wilderness and return with a story to tell—this is a measure of utility, as it relates to scientific labors. To put it another way: why guess when you can measure? A poet might write a sonnet about the forest; a wonk performs the scansion. Lest I mire myself or others in the tarpit of language, I will deliberately point out the usage of metaphor to describe the workaday activity of a scientist. If this instinctively repels you, consider the frequent romanticization of science after a significant result has been achieved. I insist that I am not putting the cart before the horse. Instead, the cart has been hitched up to a different beast of burden entirely: in my case, probably a mule rather than some more elegant creature.

3. Take me home, country roads 🎶

I began the preceding section with that fragment from Bacon because I think it offers us an interesting juxtaposition, consonant with the one we have so far been considering. These days, it is common enough to demean the pursuit of art as not useful; the final products, the masterworks enshrined in museums and galleries—these can be freely praised, but any intermediate steps by which the artist can or does arrive at a finished product should be looked upon at least with suspicion if not outright derision. Not useful because it isn't curing disease or ending poverty, goals so wildly abstract3 that they have attained a different kind of concreteness in the mind of their chasers.

Of especial relevance to us is the not-so-subtle, but relatively undiscussed, shift in meaning. Art, as Donald Knuth tells us, is that human effort which applies theoretical understanding to real-world tasks. It is clear to me that this demarcation is by no means perfectly rigid. It admits of edge cases, gray areas, and subtle contours. It is clearly informed by a modern and comprehensive account of science/art that includes, perhaps only by mere chance of history, the discovery of quantum mechanics. That this definition was current as recently as the 1970s is instructive. I assert that it is no longer so: today, art is anything which is not science, anything that is not concerned with making money4 or "doing good things for society." At its most reactionary, this turn in understanding is demonstrated through deliberate attributions of weakness or sentimentality or—dare I mention it at all—a kind of effete nihilism that wants to, it seems, tear down the edifice of scientific discovery in favor of some notionally more positive and whimsical weltanschuung.

4. The way out

The American philosopher Richard Rorty developed, over the course of his life, a framework that helps us understand truth as a product of consensus, as opposed to the ineffable and ephemeral object of persistent and thorough intellectual activity, unattainable by the masses. His task was to reverse the damage done by centuries of his predecessors' work. He was motivated in this effort by a profound respect for political democracy, public education, and free discourse.

While those are all estimable principles, they don't map too neatly onto our considerably narrower field of interest. Our (my) task is to suggest the possibility that Bacon's idea of truth or use might be better framed as truth and use. That is to say, truth and use have some overlap: but it's not a one-to-one correspondence.

I am not sure if it would be an act of bad faith to admit that I suspected this from the start. I did remark that it probably doesn't matter whether people consider making software an art or a science. I also pointed out, in the inaugural part of this exploration, that these ideas remain well outside the realm of day-to-day work, that is "writing code." But then, one day, it begins to matter, and we don't put any thought into when or why.

It takes on significance in debates about job titles. People call themselves software architects and insist this is an historical artifact, or else an ironic acknowledgement of a bygone era that is too far in the past to look upon anymore with something besides good-natured detachment. It crops up in weird pedantic constructions like "prior art."5 Where it becomes interesting, in my estimation, is in the endless slogs through principles like "design."

Suddenly, software isn't so scientific any longer. At a certain level of a corporate hierarchy, things become too abstract to be quantitative. You have to start caring about things like the attitudes of people who work for you—maybe you will even dare to challenge them by asking if they have reservations about your decision-making abilities. Worse yet, art forms like psychology take on a new relevance.

The gravest outcome is that bad software, sometimes even outright harmful software, dominates the field and saturates the market, to use two different metaphors for the same event. Some people have endeavored to combat this feature of our modern society by thinking critically, and creatively, about software design, as I am trying to do here. Yet, it is my belief that most of the efforts to bring "design"‪—that is, an artistic sensibility—to the wider world have been a failure.

To my mind, the broadest frontier of "design" is not the one that contains making the latest web app, or SPA framework, or AI chatbot. It is, and has been for some time, the one on which we watch the most gifted individuals in this profession design the tools we use to do our jobs. When the buck finally stops, these are the programming languages themselves. The next post in this series will examine this subject.

Footnotes:

1

Actually a lot of people, as far as I can tell. Keep reading…(please)

2

As noted by Knuth himself.

3

For a definition of this word lamentably "beyond the scope" of this humble blog post, I invite you to read GWF Hegel's short essay "Who Thinks Abstractly?"

4

That this end has been in any way sanctioned as a goal of "science" is not made more acceptable to me by draping it in the fabric of microeconomic necessity (i.e., talking of science as a "job")

5

On "prior art," see post #1 in this series. As for the metaphorical nature of job titles, I think it is worth mentioning that, in the case of terms like "developer" and "architect", software plays the role of a modifier. This runs counter to other metaphorical examples of naming jobs, e.g. a "staff officer" in the military, where the indirect and creative label is simply an adjective: the significance of the name, i.e. "officer," remains in the noun.