Software Is Humanities

These rambling thoughts explore the idea that software now has more in common with the humanities than it does with engineering and science. If you find some of my ideas contradictory, well, so do I. These thoughts are mostly experimental, so please correct my mistakes and provide the clues I didn't have. -- WayneConrad

Our bosses have long wanted us to be called engineers because it lends an aura of predictability to what we do. After all, when you contract an engineer to design a bridge, he is able, with a fair degree of certainty, to tell you how much material it will take and what stresses it will bear. There is a fundamental differences between our craft and that of the civil engineer that make that kind of long-term predictability impossible, at least for now. Alas, just giving us the name "engineer" does not make those differences go away. We are still unable to predict what you'll get and how long it will taketo the degree that would make producing software seem less like rolling the dice to the people paying for it.

The difference is that we have pretty trustworthy models for bridges. An engineer can construct a model which predicts the stresses on the bridge. The model can be changed to explore different materials or different types of bridge. The model, as well as being able to predict that the bridge will remain standing, can be used to predict the resources it will take to build the bridge.

We don't have anything quite like that for software. Why?

One reason might be just the relatively immaturity of software. People have been building bridges for thousands of years, and have been applying mathematical models to bridges for at least a hundred years.

It doesn't help that our building materials are in constant flux. A bridge builder gets to chose a general type of bridge -- say box girder -- then the general type of materials -- prestressed concrete -- and then specific materials -- this cement with this aggregrate and this rebar. For each of these decisions the engineer has data that he can use to refine the model and predict the behavior of the bridge. That cement can withstand so-much stress, that rebar has a proven strength of such-and-such, and when the two are combined into a beam in this well-known way, the model predicts that the beam will have certain properties. We then know that the beams, when attached to each other in a certain way, will have certain other properties we desire, such as not falling down. And we trust the models fairly well, since, for the most part, our bridges don't fall down. That we make such a fuss when a bridge does fall down shows how well we've come to trust the models we use to make them. A bridge that fell means that the model wasn't followed, or the model was wrong, both of which are very disturbing to us.

In fact, in the early history of concrete box girder bridges, many of them did fall down, for both reasons -- inadequate models and construciton mistakes. The models were changed to reflect our learning, and building codes were updated to explicitly disallow some of the mistakes that had allowed the bridges to collapse.

But in computing, the building materials change daily. You get a different amount of memory and CPU cycles all the time, and a different operating system that uses the resources differently, and new protocols, and changes to old ones, and new languages, and changes to old ones -- this incredible rolling ball of change. You all know what it's like to ride this ball. Hang on! It's like the early days of railroading, when nobody could predict whether an engine would work, or not work, or explode, or not explode, because no two designs were alike. There was no trusted body of evidence to show what worked and what doesn't. If you look at a lot of the evidence we think we have, you find that we just don't trust it. And that's because the bulk of it was produced by people with a stake in the outcome -- by a seller of a technology, or an inventer of a methodology, or someone who needed their next grant. We rightly look at the claims of these people with a bit of scepticism, because we know that it is in their interests to be biased towards whatever it is that allows them to have a home and eat food.

Even in academic circles, there seems to be a lack of useful comparative studies -- a lot of the published material seems to say a lot about the publisher's favorite solution to the world's problem rather than objective studies of one process vs. another, or one language vs. another, etc. In their defense, it is a hard thing to study -- it's very difficult to compare apples and apples. And for the kinds of problems we're interested in, such as "Which development method will result in this 6 month project having the best chance of success," these things are expensive to study, too. Nobody wants to fund two sets of equally-skilled developers to work on an identical project for six months to see what difference it makes if they use CRC cards vs. use cases. So instead of the kind of studies that we can look at and say "obviously," we get the kind of studies that drives us crazy trying to interpret them -- more like anthropology than anything else I can think of.

Even something that would seem simple to study, the eternal debate of keyboard vs. mouse, becomes difficult as you realize that each study measured very specific things that do not allow you to predict what will happen in your situation without doing some very iffy extrapolation. If a study measured use of keyboard vs. mouse for editing small pieces of text by inexperienced users on a monochrome screen with a single font, how can you use the results to decide whether a mouse or keyboard is better for selecting menu entries on a color display with multiple fonts by experienced users? Things will improve once we have a body of principles that we trust. We're like people studying gravity before Galileo. We can predict that most things will fall, but we can only make tables of how long it takes something fall. We don't have a model that lets us predict how long it will take a mass we've never dropped before to reach the ground. Until we do, we cannot do what other engineers do when they engineer something.

Another way to think of our profession is as being similar to that of medieval cathedral builders. Like us, they are not engineers in the modern sense of the word -- they don't have good models they can use to predict things. And like us, their buildings fell down sometimes. Although in my mind, they were in a far advanced state compared to my profession, as many of their buildings stood, and are still standing, and are still valued and appreciated. Some of mine have fallen down. Some were completed but the owner didn't like them and razed them to the ground, ordering another to be built in its place. Some of them were strong, beautiful, and appreciated, but the ground shifted underneath them, forcing the owners to abandon them for newer buildings. Of all of the applications I've worked on that were done more than two years ago, exactly one that I know of is still standing and providing real value to someone. One.

I hope you've done better than me, fellow cathedral builders. -- WayneConrad

A 'millennium' bridge - a footbridge over the Thames was built recently at great expense. When it opened it was found to oscillate when people walked across it. The problem - the 'engineers' had not taken into account the fact that people can walk in step. This phenomena has been known for a long time - the military know to break step when crossing a bridge. We've been building foot bridges for thousands of years yet engineers still make these basic mistakes. I think that engineering is sometimes overrated -- a software 'engineer'

The bridge was actually of a very unusual design - intended to resemble "a blade of light", as it was phrased, the suspension cables lie almost in the plane of the footway of the bridge. There was no really easy was to test for the oscillations, and actually no predition of them happening. The problem occurred because of several things; people do tend to naturally fall in step with oscillations on bridges, but normally this is less of a problem because the oscillation is across the suspension cables. Since this was firstly in line with the cables, and secondly rather resonant with them, the bridge began to swing side to side. As it did so, people staggered, and that staggering actually /powered/ the oscillations and brought more people into step, rather than causing people to break step and depower the oscillations.

The phenomenon had not been seen before because no-one had built a bridge of this design before: suspension bridges normally have cables running up/down, not sideways. And even real-world engineers can't exhaustively test. Of course, once you know it's a possible failure mode... -- KatieLucas

It could be that what we do may never become engineering. The idea that we can become like engineering (or the clearly insane idea that we are already doing engineering) comes from our art's ties to the culture of mathematics. Engineering, after all, is based largely in mathematics and in the hard sciences, especially mechanics. So perhaps, since computers also have their roots in mathematics, what we do could also become engineering. However, I am becoming more and more certain that anthropology and architecture are better matches for how we understand and perform our art than mathematics and physics are, even though mathematics and physics are crucial to what we do.

So much of our minds are reflected in these machines, in the programs we feed into them, that the approach of mathematics, upon much of what our art is based, runs into problems very quickly when it's applied to computing. Now, I know there is such a thing as computer science, and it deals with the parts of our art that are ameniable to mathematics -- can you prove that this loop will terminate, can you decide how long that algorithm will take to sort the file, can you prove that this language can solve any computable problem, and so on. We could not perform our art without this underpinning, any more than an architect could build a building without some knowledge of the materials and construction techniques it would take to build it. But what mathematics deals with are only the building blocks, the very lowest level of what it is that we do. Physics matters to an architect because the building does have to contend with physical reality. But nobody would want to live or work in a building designed by a physicist without regard for the rather critical fact that the buildings house humans. And that is why the architect's world is so much about what makes humans tick, and so little about physics.

One event that shows that what we're doing is more of a mushy, imprecise, artsy-crafty human thing than a hard science is the shift towards patterns as a way of teaching each outer what we've discovered. Mathematics tends to be mostly about axioms and theorems, and much of computer science has gone that way too. And some very valuable things have come out of that. But you can only go so far with that approach when there is so much of us, so much of our humanness, reflected in these machines. The idea that a pattern should describe existing practices clearly shows that patterns, at least, are in the realm of anthropology, not mathematics. For in mathematics, inventing now things is pretty much what it's about. You are expected to create now ideas if you are a mathematician -- describing existing ideas is left largely to textbooks and undergrad papers. But you get laughed at in the pattern community if you make up a pattern that you can't show existing instances of. Why is that? For the same reason that we would laugh at an anthropologist who submitted a study of a made-up social group. The study of anything with very much humanness in it has to be grounded in something real, something that exists, because otherwise it's just so much useless handwaving -- the human brain can imagine so many things that we decide to only codify as patterns the things that we've seen some proof of, some indication that they worked at least a few times. Otherwise we'd be overwhelmed with a sea of mostly useless ideas.

That patterns have caused such a great improvement in our art in such a short amount of time shows just how much we had run up against the limits of mathematics. We needed that mathematical foundation (and still need it) to make sure that these machines work, that what we are trying to do is possible. But what we do with the machines is so incredibly human, has so much of us in it, that a mathematical approach only helps us up to a certain point. It can only make sure that it's possible for us to use these machines to further our very human and unquantifiable purposes. After that, the study of what we do belongs more to the humanities than to the sciences. -- WayneConrad

Another way to look at this difficulty we have with programming being engineering is as a problem of constraints. In the early days of computing, we were constrained very tightly by the hardware, by what the machine was capable of at all. The programmer had to be very clever indeed to make the machine do even the simplest things fast. We were constrained by the machine -- it made sense to use lots of the programmer's resources to optimize the machine's resources. Recently -- say, in the last 10 years -- the hardware most of use is now capable enough to do most anything we want to do with it. We are no longer so constrained by hardware that it's worth our time to optimize the machine's resources. The are edges on this, to be sure -- there are still plenty of places where you do have to be concerned about resources, but they don't tend to be down at the unrolling-a-loop level they used to be at. But for the majority of software, you no longer worry about RAM or cycles or disk space. It's just not an issue. But it's taken a long time for the culture to catch up to this change -- many programmers who don't need to worry about resources the way we did in the 50's or 60's or 70's are still doing so, because they're being taught by the programmers and textbooks that came out of the era when you very much had to worry about that. There are programmers who use the boundary cases, those cases where optimization is very much needed, to justify continuing to pretend that the machine is always the critical constraint. They do that in part because it's fun, because there was a real problem-solving high from making the loop run a little faster or the sort take less memory. They miss that high. And in part, I think, just from habit, from not having noticed that the territory has changed, that the constraint has moved from the hardware to themselves.

So now we are unconstrained by the hardware, and the constraint falls on us. And what do we discover? We discover that we don't know how to build large software, the kind of software that the hardware now allows us to build, very well. So the search is on, for ways to model software, for processes to use to implement, for better tools to build it, and so on. Because the constraint was no longer the hardware -- it was our technical knowledge, it was our languages, our ability to use patterns, our tools. The constraint has moved into our heads, but we are still so busy building tools and learning how to work in this expanded landscape that it still feels to us like computing is a technical problem.

But something interesting is happening now. In a very real way, we are discovering how to solve these technical problems -- these engineering problems. Sure, we are still in the early phases, and our buildings still fall down, but we're starting to get a handle on this stuff. And those who don't have too much trouble building the kinds of software that people want to pay us for are noticing something interesting. They're noticing that the constraint has moved again. It's no longer in the head of the developer. Instead, the critical constraint that is keeping us from doing it better is in our interaction among ourselves. It's entirely in the human field now, in how we work with each other as we solve problems. There's still enough of a struggle with technical goodies that we get distracted into thinking that what we do is a technical problem, but it's becoming less and less so. Making good software is a human problem. And that's why some of the processes are focusing upon that interaction, upon how we decide what to do, and how we decide what's done, and how we decide when to change what we're doing. Because the interaction between people is now the critical constraint. -- WayneConrad

CategoryComparisons