When you're fighting for ease of use, you can't make your users forget their preconceptions, you have to adapt to these externalities.
I think sometimes engineering and software development have different degrees of freedom, but the difference isn't as clear cut as you make it.
Building a bridge doesn't have much of that: the bridge must withstand loads from the traffic, loads from the elements, material wear across decades; all that without falling down. There are aesthetical components to choose from but generally you can't avoid physics and financial cost when building one.
In programming you could choose to go with a number of alternate implementations that are as different as they would be unrealistic if only you were building a bridge instead of software. Anything from tying inflatable boats together to form a walkable chain to act as a bridge to draining all the water out and building a 6+6 lane highway across the bottom of the bay instead.
Performance is a likely domain for coming to terms with the limits of the physical qualities of computers but even then there are lots of different flavours of performance to consider, and innumerable ways to trade performance in and something else out.
Many software projects are profitable without being anywhere near physical limits. Other software projects are not, if you are working for an HFT, then you're counting microseconds and measure distances by how long it takes light to travel. If you're storing 10^10 bits of data you don't need to even think about it, at 10^15 bits of data you can go to the store and buy a bunch of hard drives, and at 10^20 bits of data you need a team of experts to make it even possible, never mind cost-effective.
If civil engineering looked like software engineering, a big chunk of our civil engineers would be building popsicle-stick bridges to carry occasional featherweight loads across 1-inch gaps, but there would still be some real bridges out there.
This even affects bridges. The new eastern span of the bay bridge didn't have to have a tower at all. They chose the more expensive option because it looks better.
As a software engineer who calls what I do "engineering", I have to answer to physics every day. The difference is that the relative cost of everything is skewed so far out of proportion to what other engineers work with that it's hard to account for the differences, and software engineers work with so many orders of magnitude. We are still working with physical stuff, basically refined sand and metal, which consumes electricity and other resources, just like other engineers.
Imagine that you were a civil engineer tasked with building a bridge. Except instead of using concrete and steel, I handed you some adamantium at the low, low cost of $0.01 per cubic meter, and a bunch of robots to machine it for you. Designing bridges is easy now, and you can basically make it look like whatever you want, just because adamantium is so amazing.
But just because we've made bridge-building trivially easy doesn't mean that civil engineering is obsolete. Adamantium is nice, and all, but now I'm asking you to build a Dyson shell, and you have to tell me that it's not physically possible, even with adamantium.
I would love to just handwave the design of the systems I work on, I would love to just arrange pieces however I felt like. Instead I have all these constraints like the reliability of components (hard drives fail), physical laws (speed of light constrains network latency), the memory hierarchy (the software manifestation of constraints on circuits), and all sorts of other problems that I can't just pretend don't exist. I have to choose algorithms that will complete with the computational resources that I have available. Maybe an exact algorithm is not physically realizable, maybe I have to choose some kind of approximation.
This is not true in mathematics. In mathematics, algorithms are not necessary (at least, for most mathematicians). In mathematics, I can prove that some object exists without concerning myself with whether some physical system is capable of constructing that object.
At the end of the day, I am writing software, and that software is one part of a real, physical system which obeys physical laws. This makes me an engineer. Maybe I play around with 20 orders of magnitude in my designs and the civil engineer plays around in 8, but so what?
Also, the industry has been pretty cavalier about measuring those costs, especially when it comes to programmer time.
I think 'working with real physical systems which obey physical laws' is necessary, but not sufficient to qualify a discipline as engineering. Architects are not typically engineers by the title, and yet they design real things, and have to worry about some aspects of pragmatic engineering when they work. Neither are applied physicists, even though their work to defines many of tools that engineers use. I'm not sure that the task of creation scales isometrically. I think there's a certain allometric aspect that means that the kind of thinking required at 8 orders of magnitude has a radically different shape to that at 20 orders of magnitude; there are still some hard yeses and hard nos (you can't build a Dyson shell out of adamantium), but the amount of grey area is vastly, non-linearly larger, and requires a lot more ad-hoc construction to work within, and thus strips away the shared language of rigor that engineering has the benefit of operating under.
I hope I haven't made it sound like I think it's completely black and white, and also that I somehow don't think software is hard. I just think it's a different kind of animal, because of the scale that it operates at, and the number of abstractions it depends on, even if it can't embrace them fully and transcend into pure mathematics.
The person that made my coffee this morning is also an engineer by this definition.
Apart from that I agree, we have real constraints to deal with and we can't hand wave away the environment the code runs in.
The verb choice is important here, someone who makes coffee doesn’t “write” coffee.
That said, any definition outside mathematics or logic is imperfect.
So do computer scientists! Random access memory isn't constant time, but logarithmic for physical reasons. Cache effects can dominate big-O for a surprisingly large range of input sizes.
A wonderful metaphor. Thanks.
Somewhat incidentally, but I believe this is a large part of why, to me, software development is not an engineering discipline. At the end of the day, engineers (I think; not actually being one myself) have to answer to physics. The 'possible model space' is relatively constrained, and everyone is working under, roughly, the same set of assumptions, rules, and standards. This kind of constraint allows for higher degrees of rigor, because there often is a 'right way' to do things, or an empirical set of tests to verify the quality of an idea.
Software is, on the other hand, only slightly more constrained than mathematics in its most basic form. We can introduce artificial constraint by monopolizing a domain with certain ideas that have proven robust and reliable (in the same way that we've decided that, in general, you turn a screw clockwise to tighten it), which in turn allows for the introduction of some engineering-style rigor and standards, but there's nothing really stopping you from stepping back and saying, "well I want to do it this way instead", in the way that an Engineer is prevented, by physics, from saying, "well, I think we should just alter the density of air so that we don't need to worry about lift for these airplanes we're building; they'll just be buoyant!". By and large, you can do that kind of thing in code; you're building the world within which you're going to solve the problem, and you can arrange that world as you see fit (by and large) to make certain aspects of the problem easier (often at the cost of making others harder), in the same way a mathematician does.
And if you've got one kind of world you really like, because it works well with how problems decompose in your head, it can, to the parent's point, be really difficult to understand why another representation might be just as useful to someone else's particular brain arrangement.
Not trying to make value judgement here, though I do envy and admire engineering rigor. Just a (likely naive) take on a fundamental difference.