Software and engineering
November 7, 2015 at 8:52 AM by Dr. Drang
My wife sent me a link to this article by Ian Bogost, because she knows the “are programmers engineers?” thing is a pet peeve of mine. I liked the article, and I think Bogost presents a good rundown of the problems in software engineering, but ultimately, I can’t go along with his main thesis. While I agree that programmers aren’t (in general) engineers, it isn’t for the reasons he gives.
Bogost, like many who take on the topic of software engineering, focuses on process, the development of a disciplined approach to programming that will yield reliable results. In this view, the difference between hacking and software engineering is like the difference between carpentry and structural engineering. The carpenter takes lumber and nails it together in a way that seems right, while the structural engineer sizes and spaces the lumber using a rational approach based on the applied loads and the strength of the material. Software engineering aspires to be analogous to structural engineering.
But there’s a place for carpentry. If you’re building a shed in your backyard, there’s no need for a structural engineer. The rules of thumb of carpentry—which can be shown to have rational bases, even though the carpenter may not know them—are perfectly adequate to build a strong and durable shed. The trick is to know when you need structural engineering and when you can get by with carpentry.
This is where construction has an advantage over programming. We have generations of experience that guide us in coming up with these rules of thumb and knowing when they don’t work. Programming doesn’t have that long history.
And when the rules of thumb won’t cut it, structural engineers have techniques for analyzing most structural components to determine whether they’ll carry the load safely. Even for components that are too complicated to allow for analysis on paper, we have standard ways of testing that will (usually) give us the answers we need to build a safe structure. Analogous standards in software are still in their infancy, and often not used. This is the basis for Bogost’s position.
I have a much simpler definition of engineering that has nothing to do with process or the reliability of results. To me, engineering is a struggle against nature using the laws of nature.1 The products of “real” engineering exist in the physical world; they are not abstractions.
By this definition, plenty of programming is engineering, or is at least in service of engineering. Device drivers are probably the best example. They aren’t simply “close to the metal,” they’re on and in the metal. They control the metal. But the programming of conceptual stuff like word processors, databases, and web pages isn’t engineering because it doesn’t have that connection to the physical world.
This has nothing to do with quality, difficulty, or intelligence. By Bogost’s definition, programmers can become engineers if they get their act together, sort of like Pinocchio becoming a real boy. By my definition, they can’t. There’s nothing pejorative about my definition. If you’d seen as much crappy engineering as I have, you wouldn’t be especially eager to be called an engineer.
I know, of course, that I have lost this fight, and programmers will continue to be called engineers. That’s OK. One of the benefits of advancing age2 is that people start treating your odd ideas as charming eccentricities instead of irritating provocations.
-
My “mother tongue” of structural engineering is probably the simplest form of engineering. It’s a continual fight against gravity. ↩
-
I confess that one of the most disturbing things I found in reading this story about increasing mortality among middle-aged white Americans is that I’m now beyond their definition of middle-aged. ↩
