Good engineers make terrible leaders
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.<p>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 &quot;far away&quot; from the hard sciences aren&#x27;t emotionally ready for. You don&#x27;t question their sacred cows.<p>Let me give you a software example which shows how basically even the &quot;tamest&quot; seeming problem in software engineering is pretty &quot;wicked&quot;, requiring some of the same skills you&#x27;d use to tackle a social issue.<p>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&#x27;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?<p>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 &quot;faster&quot; and if it&#x27;s the right number.<p>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.<p>We might say that page download time is a poor metric because if I&#x27;m some poor schmuck trying to visit a page, the time that the html took to download doesn&#x27;t really mean anything to me.<p>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.<p>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 &quot;tame problem&quot; with a objective stopwatch for measuring.<p>We kind of &quot;knew&quot; the right measurement was one that the human interacting with the web page would intuitively understand as &quot;website A is fast&quot;. How long until they could see the page, how long until they could &quot;touch&quot; it and interact with it?<p>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 &quot;complete&quot; document. So almost by definition it wasn&#x27;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&#x27;re calling it next week. Content loaded often was too conservative of a measure. It didn&#x27;t fire until the last image had downloaded and rendered. That could be below the fold and as they say: &quot;out of sight out of mind&quot;.<p>So at this point if we want to answer the question: &quot;is website A faster than website B?&quot; we only know the real answer is somewhere between 2 numbers.<p>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 &quot;app&quot; wasn&#x27;t done rendering, you could say: &quot;a customer could see the page and interact with it without those interactions being lost&quot;.<p>So if we want to measure &quot;when can I see a webpage and start interacting with it?&quot; it&#x27;s a pretty tough question that might not have an answer. The best we can do is say: &quot;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.<p>You can make videos of websites rendering and visually compare them.<p>I&#x27;ve spent my career as a performance engineer and I don&#x27;t really know how to, in the general case, answer the question: &quot;is website A faster than website B&quot;. In specific cases it&#x27;s sometimes clear. For example I could visit a static html page with no buttons and say: &quot;it was definitely loaded in 50ms&quot; and then visit some monstrosity of a single page app that displays a loading screen for several seconds and conclude: &quot;the static webpage was faster than the app&quot;.<p>But I&#x27;m sure designing a bridge is sooo much simpler and there&#x27;s no ambiguity there.<p>Right?