I thought it kind of odd the author asked randos off the street to define "engineering"
Back in '47, the ECPD, which later more or less turned into the ABET, used the definition:
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."
It would seem programming-type-stuff is more of a technical craft than an act of engineering. Ideally on the best days on projects of small scope, programming can approach engineering levels of rigor.
The tolerance for bugs is vastly higher in programming than in structural steel engineering, for example. There are no valid statistical analysis techniques for programming to reliably predict quality of code, although infinite conflicting opinions exist alongside some rather trivial rules. Some "full stack" types approach full cognizance of their design; but its rare outside narrow areas like embedded or device driver designers. Economics of operation is usually hand waved away with "moores law" and "batteries always get better over time", and environmental impacts (aside from mere greenwashing and virtue signaling) are ignored. Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard, programmers are like "here's a URL to the docs for the API from a couple versions ago best of luck to ya".
I'd say on the technical continuum that programming is very much like village blacksmithing. Somehow in general the horses get horseshoes but its not cheap, efficient, safe, clean, predictable, or fast.
The future being distributed very unevenly, I'd predict we'll see the first widespread "real engineering" of computer-stuff appear in corporate IT departments probably revolving around statistical analysis of cloud computing.
Mechanical engineering has specifications for "bug" tolerance.
These are manufacturing tolerances and safety factors.
Unless you're testing the piece of steel you're bout to use, you don't really know that it's yield strength is what the box says. Similarly, the welding might be done by an apprentice with a bad teacher, and during maintenance, the repair guy might run out of a certain bolt and use a different one with a washer.
Keep in mind that you do things to alleviate the possibility of "bugs"
When you purchase Steel it is purchased to a specification (such as minimum yield strength) if the steel fails to meet those specs the supplier can be held liable.
In software terms I suppose the equivalent would be purchasing a commercial library with support from vendor.
For major construction projects welds are inspected and singed off on, they may be tested as well.
Again in software terms equivalent would be code audit and test cases.
In construction there is a lot of inspecting stuff, signing off on it and certifying stuff. I think software people would go crazy if they had to deal with the same amount of paperwork.
> Mechanical engineering has specifications for "bug" tolerance.
That's what these days is referred to as an SLO.
Golden signals, USE, RED are ways of measuring them on a high level.
You program your systems to be resilient to a certain level of failure (retries, graceful failure), and you program them to be able to cope without a malfunctioning part by isolating it from the rest of the system (circuit breakers, bulkheads).
> Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard
Last year I took a job from a surprisingly big car manufacturer. They had designed and built a 2 million dollar glue dispensing machine. Only after it was fully assembled did they realize that they didn't have a way to get the glue into it. They needed it to be running the next week. Engineers run into bugs all the time, we just don't get convenient error messages.
Back in '47, the ECPD, which later more or less turned into the ABET, used the definition:
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property."
It would seem programming-type-stuff is more of a technical craft than an act of engineering. Ideally on the best days on projects of small scope, programming can approach engineering levels of rigor.
The tolerance for bugs is vastly higher in programming than in structural steel engineering, for example. There are no valid statistical analysis techniques for programming to reliably predict quality of code, although infinite conflicting opinions exist alongside some rather trivial rules. Some "full stack" types approach full cognizance of their design; but its rare outside narrow areas like embedded or device driver designers. Economics of operation is usually hand waved away with "moores law" and "batteries always get better over time", and environmental impacts (aside from mere greenwashing and virtue signaling) are ignored. Engineers use reliable and predictable statistical process control methods to ensure mass produced parts work together under a well defined standard, programmers are like "here's a URL to the docs for the API from a couple versions ago best of luck to ya".
I'd say on the technical continuum that programming is very much like village blacksmithing. Somehow in general the horses get horseshoes but its not cheap, efficient, safe, clean, predictable, or fast.
The future being distributed very unevenly, I'd predict we'll see the first widespread "real engineering" of computer-stuff appear in corporate IT departments probably revolving around statistical analysis of cloud computing.