Software Is Applied Philosophy

Yesterday, I wrote an entry on science as a coping mechanism for dealing with complexity.

It’s a fairly lengthy and philosophical piece. I originally intended to structure things a bit differently, but once it started to get long, I decided to split things up.

It would, after all, be somewhat ironic to spend three pages arguing that good science is based around breaking things into mentally manageable chunks and then, having reached a potential stopping place, water down my point by stuffing more information into the post.

Which is central to what I would like to focus on: establishing boundaries. The previous post started a concept by Patrick Grimm that over time rational models go from being broad philosophical abstractions to specific systemitized sciences. I added the idea that the systemic boundaries are not necessarily “natural” characteristics of reality, but rather that they are drawn to deal with the limited capacities of our mental hardware to deal with complexity.

For a somewhat expanded (and more entertaining) version of that argument, consider reading Lewis Padgett’s Mimsy Were the Borogoves.

My purpose in writing, however, wasn’t a philosophical treatise. Philosophy is a fine pursuit, but I’m a bit more pragmatic in my tastes. I prefer statements that are more concrete and debatable. My actual point was forwarding a discussion Matt and I have been having about software configuration.

Part of the reason the systemization of conceptual structures leads to testability is linguistic precision. Consider on of the most philosophical fields: religion. If I ask 100 people if the war in Iraq is immoral, depending on how specific a rationale I ask for, I am going to get 100 different answers. The meaning of the word “moral” has no widely defined social meaning.

Consider this in contrast to if I ask how many states there are in the United States. Unlike with the word “moral,” if there is any disagreement on the issue it will be over the definition of the word “state” rather than the word “fifty.” We all agree very precisely on what fifty means and it is not generally debatable.

Which is another major function of systemization. Once we have a system where the terms are well defined we can manipulate those symbols as wholes rather than worrying about any ambiguity in their understanding. While discussing the rigid systemization of mathematics with Matt today, he said, “If you look at the work that happened around 1880-1920, with Church, Turing, Goedel, Russell, et. al, you see that computers ‘fell out’ of that.”

My argument is that this was no coincidence. It is the same reason independent researchers frequently discover the same thing. It isn’t simply that the field is progressing in a certain direction toward the discovery of some ephemeral truth, but that only once a certain level of philosophical abstraction is defined with the proper level of precision can those ideas be used to define the next level.

Think of it as juggling. A normal trained juggler can keep three or four things up in the air at a time. The world record is nine balls. It doesn’t matter how much you really really want to, if I give you ten balls, you probably aren’t going to be able to juggle them. Imagine though that you manage to glue the balls together into groups. Once those groups are stable enough, you can juggle those because it isn’t the size that’s a problem, it’s the complexity.

So, systemization is about the capacity to unambiguously express an idea frequently in terms of layered metaphors. The reason I’ve been discussing the progression from broad philosophical concept to a specific science is this is software engineering in a nutshell. Computer programming is, arguably, the most unambiguous method for describing a conceptual structure that we’ve got. Two people can take an idea that is codified as a computer program and always draw the exact same result.

Matt, as he is apt to do, in responding to my last post jumped ahead to the fact I was going to write about programming. (I’m not sure if he knew that was where I was headed or not.) He posted a link the The Programmer’s Stone.

I’ve only read the first couple sections, but so far, the Programmer’s Stone is dividing people into “packers” and “mappers.” Their description really serves two purposes within the book. One is to actually define a useful set of characteristics that a good programmer has, the other is to establish an “Us” (Mappers) perspective from which the rest of the book describes a “Them” (Packers).

Packers are agents of the Man who think software engineering is a fixed process and programmers are just bricklayers sticking the right programatic bits together to code a solution to a problem. Mappers recognize the inherently creative act that computer programming is. Mappers absorb the problem domain and come up with elegant and simple solutions.

I think that the distinction is a good one, but I think the dualism is aritficial. Kasten Wagner’s post on why programming is difficult comes closer. He doesn’t even define Mapping and Packing as the ends of a continuum. There are iterative levels of Mapping until eventually everything is completely specified (which is Packing).

The main difference between computer science and most other sciences is whereas systemization takes place over time and develops other sciences, in computer science systemization is the science. Computer scientists are essentially given problems by the other sciences (be it physics, psychology or marketing) and are asked to systemitize their problems to the point that the abstraction can be handled by a computer.

I think that is one of the characteristics of the best programmers I know. They recognize that they are designing abstractions and that the design of an abstraction, in programming as well as philosophy, is a balance between the expressive power of the abstraction and its complexity.

Recognizing computer programming as the science of systemization begins to give us a handle on the question of “how do we program?” Much like it is difficult to evaluate concretely whether or not an action is “moral,” it is difficult to evaluate whether a piece of software is good or bad when the job of a programmer is simply “make the computer do stuff.”

If the job of a software engineer though is to design a set if layered abstractions to systemitize a conceptual structure from a particular discipline then that begins to give a more solid set of criteria for evaluating the task. In particular it makes methods of systemization (design patterns and language constructs) not simply extraneous bits of knowledge that programmers learn for fun, but a legitimate conceptual structure that can be used to evaluate the quality of a piece of work.

One of the big issues that is affecting the field of computer science currently is it is hard to determine if a programmer is good or not. I think this is in part because there’s very little consensus within computer science as to what the actual point is. It isn’t simply that we haven’t established some special certification test to make people pass. The lack of a consensus on the point of computer science means the level of systemization of the field is staying fairly low.

It isn’t a lack of a diploma that keeps a person from pretending to be a mechanical engineer. It is because the field has developed some sophisticated conceptual tools for doing what it does — stress mechanics, differential equations, etc. Someone without those conceptual tools can’t produce the same sorts of output that someone with them can.

This doesn’t mean making things unnecessarily complex. My entire point throughout is that being aware of the influence of human cognitive limitations on the segmentation of conceptual structures is crucial for designing good ones. What it does mean is that the bulk of computer languages and APIs operate essentially at the level of elementary logic. If there was consensus on methods of systemization then tools could be designed that operate with those higher level specialized concepts. These tools, because they are mapping across broader structures should be operationally more efficient. (If they aren’t then new, more effective abstractions can be found.) Someone wandering in off the street would not be able to just dive in and start programming at the level of a software engineer because they wouldn’t have the proper conceptual model of systemization.

(I didn’t get around to writing about configuration again. I did move it a step closer however. I’ll do one more of these that is a case study and takes into consideration configuration. For now though, the gym beckons.)