People who try to box engineers into some sort of hyper-rational over-simplified box to separate them from real world messy problems are silly. I suspect the u

People who try to box engineers into some sort of hyper-rational over-simplified box to separate them from real world messy problems are silly. I suspect the underlying reason is that once you start measuring things, you tend to learn thing fast and that typically shakes up the status quo in a way that disciplines "far away" from the hard sciences aren't emotionally ready for. You don't question their sacred cows. Let me give you a software example which shows how basically even the "tamest" seeming problem in software engineering is pretty "wicked", requiring some of the same skills you'd use to tackle a social issue. Is website A faster than website B? What do we mean by fast? Sure we agree we can use a clock, and to bucket relativistic effects we can talk about things on planet earth. So if you're sitting there in front of a computer with a clock, what should you measure to tell if website A is faster than website B? The answer is nobody really knows but some answers seem better than others. The most simplistic measure is to measure the time from when a request is sent to when the last byte of the response is received. But once we have a number we have to ask what it means in terms of "faster" and if it's the right number. Some single page apps these days are really fast by that measure. They just give you a static shell, that would sure beat the pants off just about any other webpage download. Of course for single page apps giving you a static shell, the initial download is not the end, but the beginning. They start to load css and javascript and images, etc. We might say that page download time is a poor metric because if I'm some poor schmuck trying to visit a page, the time that the html took to download doesn't really mean anything to me. For a while people thought time to first byte was more interesting. Of course it really means nothing, but in some cases, for a short while (streaming pages from jsps, etc) before mvc became the predominant paradigm, a good ttfb was correlated with sending some html that the browser could get to work on, allowing it to render content sooner, which seemed like a good thing. Do you see the wickedness here? In order to even tackle the problem we have to invent measures and targets, even though this is a "tame problem" with a objective stopwatch for measuring. We kind of "knew" the right measurement was one that the human interacting with the web page would intuitively understand as "website A is fast". How long until they could see the page, how long until they could "touch" it and interact with it? As people started doing more javascript, the approximation of TTFB stopped being as useful. There were easy things to measure, domready and page loaded. Dom ready meant that a page had loaded enough for javascript to begin interacting with a "complete" document. So almost by definition it wasn't a good measure since it marks the beginning of the lifecyle of an AJAX app or client side mvc or single page app or whatever we're calling it next week. Content loaded often was too conservative of a measure. It didn't fire until the last image had downloaded and rendered. That could be below the fold and as they say: "out of sight out of mind". So at this point if we want to answer the question: "is website A faster than website B?" we only know the real answer is somewhere between 2 numbers. Of course facebook cheated. They attached event handlers to the body pre-domloaded that just appended events to a Array (queue) so that people could see a button and click on it and even though the "app" wasn't done rendering, you could say: "a customer could see the page and interact with it without those interactions being lost". So if we want to measure "when can I see a webpage and start interacting with it?" it's a pretty tough question that might not have an answer. The best we can do is say: "you loaded a web page at time t0 and at time t1 you performed an action and it (did|did not) work. We could compare those 2 things... if the action was something you could do on both websites. You can make videos of websites rendering and visually compare them. I've spent my career as a performance engineer and I don't really know how to, in the general case, answer the question: "is website A faster than website B". In specific cases it's sometimes clear. For example I could visit a static html page with no buttons and say: "it was definitely loaded in 50ms" and then visit some monstrosity of a single page app that displays a loading screen for several seconds and conclude: "the static webpage was faster than the app". But I'm sure designing a bridge is sooo much simpler and there's no ambiguity there. Right?