Bridges, Software Engineering, and God

Based on the number of times I've seen the comparison come up in my career, you might think that bridge building and software development were related in some way:

[..] my Dad, who is a "real" engineer, is out visiting for a few days. We got talking tonight about the essence of real engineering and attempted to understand if software development is approaching the level of say mechanical or chemical engineering in terms of maturity of the field. (Brad Abrams)

[..] building software is an immature engineering discipline, which most notably shows in our lack of ability to make true black boxes. "Classical" engineering, like building bridges, dams, and other structures, has mastered the art of specifying components to such a degree that they can be described with only a few parameters. In the art of software engineering, we do not have this down yet. (Kees Leune)

"Our standards have inappropriately been lowered by our daily experience," said Ken Jacobs, Oracle's vice president of product strategy. "We have to bring software engineering the kind of maturity we have in building bridges and buildings. We don't expect buildings to fall down every day."

I find these discussions extremely frustrating, because I don't think bridge building has anything in common with software development.* It's a specious comparison. Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.

Traditional bridge-building engineering disciplines are based on God's rules-- physics. Rules that have been absolute and unchanging for the last million years. Software "engineering", however, is based on whatever some random bunch of guys thought was a good idea in the early 1980's. We don't have the luxury of working within a known universe. God didn't invent x86. That makes the comparison with traditional engineering disciplines tenuous at best. More than half of everything I know will be obsolete in ten years; can any civil engineer say that?

In "Computer Science" is Not Science and "Software Engineering" is Not Engineering, B. Jacobs proposes that software is more like math:

So, if physical engineering is applied science, but software design does not follow the same pattern, then what is software design? Perhaps it is math. Math is not inherently bound to the physical world. Some contentiously argue that it is bound because it may not necessarily be valid in hypothetical or real alternative universe(s) that have rules stranger than we can envision, but for practical purposes we can generally consider it independent of the known laws of physics, nature, biology, etc.

The most useful thing about math is that it can create nearly boundless models. These models may reflect the known laws of nature, or laws that the mathematician makes up. Math has the magical property of being able to create alternative universes with alternative realities. The only rule is that these models must have an internal consistency: they can't contradict their own rules. (Well, maybe they can, but they are generally much less useful if they do, like a program that always crashes.)

Software is a lot like math, and perhaps software is math according to some definitions. The fact that we can use software to create alternative realities is manifested in the gaming world. Games provide entertainment by creating virtual realities to reflect actual reality to varying degrees but bend reality in hopefully interesting ways. A popular example is The Sims, a game that simulates social interaction in society, not just physical movements found in typical "action" games.

The hypothesis that software is mathematics is certainly more credible. But like Rory, I'm not even convinced that math and software are all that similar:

When I was growing up, I remember hearing people say things like, "If you like computer programming, then you'll love math." I always thought that these people were absolutely nuts. While there is something intrinsically similar about certain types of math and computer programming, the two are different in many more ways than they are similar.

With math, and I'm not talking about the crazy number-theory math philosophy "Do numbers really exist?" side of things, but with the applied stuff, there are correct answers. You're either correct or you're incorrect.

With coding, the best you can hope for is to do something well. With so many different ways to effect a single outcome, it's up to some very right-brained sensibilities to determine if you've met your goal, as there isn't anybody (except [another more experienced developer]) who can tell you if you're right or not.

If you ignore your right brain, and I'm talking generally about abstraction and aesthetics, then you can slap some code together that might work, but it also might be one hell of a maintenance nightmare. If you focus only on the right brain, you might have something that works, but is so utterly inefficient and personalized that you're the only person on Earth who could make sense of the code and maintain it.

Unlike math, software can't be objectively, formally verified to be correct. Or even good, for that matter.

Software development is unquestionably a profession, but I don't think we can learn as much from the fields of mathematics or traditional engineering as is so often assumed. However, we do have a lot to learn from ourselves. Disseminating best practices to other developers is our biggest challenge, not adapting processes from unrelated industries. I recommend reading through this recent interview with Steve McConnell for his thoughts on how much the field of software development has advanced in the last 10 years-- and how to keep advancing.

* However, it is fun to build bridges in software!