Constraints

Over the years I’ve seen many people say that software engineering isn’t real engineering. They tend to come up with the same reasons, even if they have different examples. In my mind I’ve grouped them into a few major reasons.

1. Real engineers work with things in the physical world. Things made of atoms, and they’re constrained by physics. Software engineers, on the other hand, work on “bits”, and bits aren’t real¹. There are no constraints on bits other than the developer’s imagination.

2. Real engineers can and do estimate their work. Software engineers can’t (or won’t) accurately estimate.

3. Real engineers have a license. Software engineers don’t.

The other day I ran across another article saying that software development isn’t engineering. It used what I think of as major argument #1 for why software development isn’t engineering. I disagreed. Besides pointing to towards the Crossover Project, there were a couple of other things that I mentioned.

First of all, as a person who was formally trained and started their career as an aerospace engineer, I have a decent idea of what goes into that work. I dealt with atoms. Mostly atoms making up aircraft in my case.

Second, it’s true that there are lots of constraints

that go into aircraft design. Balancing weight vs. lift, thrust vs. drag, useful payload vs. takeoff weight. Range vs. loiter time vs. acceleration. All of these things have limits based on physics, available technology, and how you choose to balance them against each other. It’s multi-variate calculus. With no right answer, only different choices. In any given situation, the answer to the question of which design is “correct” is It Depends.

Taking them in turn, while your typical civil, mechanical, or aerospace engineer is working on buildings, infrastructure, vehicles, and other very large, very physical things, that’s not the only kind of traditional engineer there is. Electrical engineers are primarily interested in are electric fields and how they interact to transfer and transport energy. Sure, they deal with wires and physical components to do it, but that’s the medium, not the focus. After all, electric current is not the movement of atoms, but the movement of holes. When you’re concerned about negative space, that’s pretty far from being concerned with atoms.

With that in mind, software engineering is about managing information flow and storage. No one would say that the people who design hydro-electric power stations, building dams, spillways, and internal plumbing aren’t engineers. Information is handled in a very similar way. Pipelines, Queues, and Long-term storage. One is water, the other magnetic fields or electron holes, but it’s basically the same thing.

The other part of the argument is that real engineers are constrained by physics. That’s certainly true. Going back to those planes I worked on, they very much are constrained by physics. There’s only a certain amount of energy in the fuel. You can only convert some portion of that to thrust. For a given shape, the lift/drag ratio is known. You have to balance those things or the airplane doesn’t work. You can’t build a plane out of Unobtanium, no matter how much faster/better/easier it would be.

Similarly, software engineers face constraints. There are the prosaic one, like clock speeds, amount of memory, and disk space. You can’t use more than you have. Then there are others that are more dependent on the current environment. Network bandwidth is a real limit. Available power is a limit. The speed of light is a limit on communication. The speed of a wavefront in a wire is a limit. Then there are things like CAP theorem. There are lots of ways to balance these things. With no right answer, only different choices. In any given situation, the answer to the question of which design is “correct” is It Depends.

There you have it. Why reason #1 for software engineering not being real engineering is wrong. Reasons 2 and 3 are topics for a later post.