The debate holy war on the topic of software engineering vs “real” engineering seems as endless as GWOT. I am too lazy to do an extensive
search, but I do remember one of the pithy definitions to claim the use of differential equations as a necessary condition…
But I thought I’d throw just one more difference into the mix. Software engineers — at least those that work in application development — have to use knowledge of other domains — those, for which software is written (e.g., finance, etc.) As far as I am concerned, these domains tend to be boring… I like technology for technology’s sake… Does that make me more of an engineer? Discuss… I wonder whether Michael Swaine weighed/will weigh in on it… P.S. Please…DISCLAIMER/DIGRESSION
I don’t really care, but “engineer” does sound cooler than “programmer”, which doesn’t have a sci-fi ring to it anymore, or “developer”, ’cause Donald Trump is also one — not that he isn’t cool…
DEBEDb 
The particular difference that people site is that if your bridge breaks or your building collapses, people die, and so there is a level of professionalism in Civil/Mechanical/Other Engineering that holds its professionals to higher standards. At the basic level, all engineers make things, and this is an argument about the reliability of the things you make. In this area, there is another difference between Software and bridges: discrete versus continuous systems. A bridge’s failure modes are easier to identify. To much stress at a given point, an input of a force X at a given point, and the bridge will fail. The engineer assumes that if force X breaks, and force Y holds, then the bridge will hold for forces less than Y and fail for forces greater than X. When this assumption fails, you get results like the Tacoma Narrows Bridge — where a shear force (wind) happened to induce vibrations at a resonant frequency. And so, a force less than Y ended up storing energy in the bridge, which built up until failure. State is hard to manage. 🙂 In software, there is no such monotonicity. Ironically, the finite number of distinct states states make the system harder to test than the infinite number of states of a continuous system. Because one state is “like” another in a continuous system, infinite states can be grouped together. Meanwhile, testing whether or not a program will crash is an undecidable problem. The difference, then, I think is what is the model for the engineer’s creation. “Real engineering” tends to be modelled by differential equations, while Software Engineering is modelled by finite state machines.
LikeLike
> The particular difference that people site is that if your bridge breaks or your > building collapses, people die, and so there is a level of professionalism in http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html > The difference, then, I think is what is the model for the engineer’s > creation. “Real engineering” tends to be modelled by differential equations, > while Software Engineering is modelled by finite state machines. Yea, I’ve heard the DQ criterion before… Thought it was cute, the argument of “it’s engineering only if you use differential equations” being on the level of “it’s a sport only if you use your hands” (“why do I hate America?”).
LikeLike