OOH, I'm cheering along with everyone else at this comment. OTOH, I wish there was a reference book or something that takes this to a usable level. Everyone w

OOH, I'm cheering along with everyone else at this comment. OTOH, I wish there was a reference book or something that takes this to a usable level. Everyone who works on software knows that similar tasks can be completed by a 6 workers, a 6 figure budget or 600 and an 8 figure budget. A similar feature costs 6 hours, or 6,000 hours... in dissimilar circumstances. Some reasons for this are probably unavoidable. Deploying a moderation feature on Twitter is just different to deploying on a 10,000 user app. Some reasons are complex, and mysterious. Overall though, it is very difficult to fathom "Why." How can efficiency possibly vary by so much?! Should we even believe our eyes? Maybe it doesn't vary by that much? I think one reason this is a nasty problem is that there are so many unrelated ways to answer it. They all yield different insights, and the different insights barely intersect... neither negating or supporting one another. You could treat this as an engineering issue. How is HN's stack, code and such engineered. That'll give you an answer. You could go one step before engineering: how do decisions/specs work? For HN, the same few head(s) decide what the site do, how to code it, moderate it, host it, etc. It doesn't change often, or much. A "minor feature" like christmas colours is probably conceived of, specced, approved, coded, released and operated by the same person. You don't suddenly discover that one of the steps is hard. An engineer doesn't have to explain to an idea person why X is harder than Y or why A creates more technical debt than B. They don't need to negotiate, compromise, or communicate in a least common denominator language. This sort of management/organisational explanation doesn't negate the engineering explanation, but it does trivialize it. When I'm in "organisational brain" mode, I think of engineering decisions (eg. writing everything to the file system) as derivative. Those decisions happen because of organisational reality. This isn't strictly true, but it probably applies in most RL situations. A bank isn't going to engineer like this. Neither is a startup team of 50 newly hired ninjas. It's tempting to forget about engineering at this point... but that's obviously wrong. Meanwhile, you can probably answer these questions 10 more ways. The team of 50 newly hired ninjas can be explained by funding. It's just what happens when VCs pour large sums into incubator startups en masse, in a tight labour market. We can go a step further: Maybe the VC stuff is derivative of monetary policies and macroeconomics... It's not untrue. You might prefer a cultural explanation. IIRC, pg like this kind of explanation. Academic culture, FOSS, or government consulting cultures will get you to different code, stack, financial structures, etc. Hiring a LISP team will get you fundamentally different software than hiring a Java team. Much more different than legibly explainable by the differences between Java and LISP. It's technically possible to do the LISP thing in Java or vise versa. It won't happen though. It just goes on and on, gets hairier and nastier as you go. I find that the deeper I go, the more I touch base with the aggravating starting point: the cost/efficiency of software varies by several order of magnitude: far more than reasonable.