What's Worked in Computer Science
As usual, read this as &quot;what&#x27;s popular in Computer Science&quot; more than &quot;what&#x27;s worked&quot;. Lots of things listed in the Maybe and No category (both the original table and in the article) <i>do</i> work but aren&#x27;t super-popular and some things listed as &quot;Yes&quot; like bitmaps and subtypes are bad but ubiquitous.<p>Apart from my usual spiel on how popularity is not particularly meaningful[1], this is also an example of a fascinating idea from poker: &quot;results oriented thinking&quot;[2]. It&#x27;s a terrible name, but a crucial concept: you can do everything right and still fail or you can do things wrong and still succeed. In Poker it means you can bet correctly and still lose to the luck of the draw and vice-versa; you can&#x27;t generalize from a single example or even a handful of examples. Of course, this is exactly what so many people in industry do. <i>Results oriented thinking is endemic in practical software engineering.</i><p>We even have our own name for it, or at least part of it: the IBM effect. &quot;Nobody ever got fired for buying IBM.&quot;[3] If you do the same old thing and fail, well, things happen. If you try something new and fail, well that thing you tried has to be terrible! Never do it again! Of course, in reality, those &quot;things that happen&quot; still dominate, but that&#x27;s not how people make decisions. Then it&#x27;s all magnified through institutional memory and &quot;common wisdom&quot;.<p>It&#x27;s also magnified because there&#x27;s a certain kind of personality that values pragmatism above all else and categorically opposes anything new, idealistic or academic. (To be fair, pretty much the opposite of me :P.) The tricky thing is that they have a point... some of the time. But they&#x27;ll use any sort of failure to rationalize their view, and because decision makers tend to be so results-oriented this sort of rationalization has an outsized influence.<p>Putting this all together both this article and Butler Lampson&#x27;s original argument tell us a lot more about <i>the social dynamics of software engineering</i> than they do about <i>computer science</i>. There are still interesting insights to be had, but <i>certainly not the ones the article is arguing for</i>.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10567962" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10567962</a><p>[2]: Unfortunately, I haven&#x27;t found a single good description of &quot;results oriented thinking&quot; as the phrase is used here. This blog post is okay, but the first part plays dubious semantic games with words that you may as well ignore: <a href="http:&#x2F;&#x2F;randomdirections.com&#x2F;why-being-results-oriented-is-actually-bad&#x2F;" rel="nofollow">http:&#x2F;&#x2F;randomdirections.com&#x2F;why-being-results-oriented-is-ac...</a><p>[3]: Hilariously, this was the first Google result for the phrase: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fear,_uncertainty_and_doubt" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Fear,_uncertainty_and_doubt</a>