Yes, the OP states a good question. My thought, going back some years, is that in some fields engineers work with strength of materials, e.g., what a steel I-b

Yes, the OP states a good question. My thought, going back some years, is that in some fields engineers work with strength of materials, e.g., what a steel I-beam will hold, and more generally work with, assemble, combine components with known properties. E.g., there are actual standards organizations that state the properties. In computing we have some of that -- components with known properties -- but not nearly enough. I'm drawn in part to the possible analogy with Lego blocks -- components can just snap together. This is a simple view, mostly because where we get to do engineering is small and where we don't, where the problems are, where we don't yet know how to do engineering, is large. Reading this thread, it looks like some others give more than my simple view here. But I cast my vote with those who also agree, with more evidence than I'm presenting here, that in computing we need more engineering. Once I did work with some people who wanted to regard a computing system as a network of queues and, then, apply queuing theory with, maybe, some probabilities and optimization. Supposedly they did apply such engineering to the design of an important I/O subsystem. So, that seems to have been an example of making software design engineering. In engineered systems, it is common to monitor the systems for correct behavior, and I was in a project trying to do the monitoring with just judgment and guesstimates, in particular, thresholds selected just intuitively on one variable at a time. Of course, thresholds on several variables, one at a time, have the geometrical region of normal performance always just a box. Well, we can't believe that normal performance is accurately a box. So with a small box, get a lot of false alarms and with a big one, poor detection rates. Bummer. Gee: Very commonly in monitoring, e.g., testing for a disease, we have for each test at least false alarm rate. We would also like detection rates. There is the famous, old Neyman-Pearson result on how to get the highest detection rate for any given false alarm rate. So, to do better than just judgment, I worked up a quite general test, with multi-dimensional data, including high dimensional, distribution-free, with known, adjustable false alarm rate and provable non-trivial detection rate. I published the thing. Soooo, that was a small step toward engineering for system monitoring. We need more engineering.