> That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project.
Sure they can. At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. (Actually there were two of them - the more famous one is the Jeff Dean version that traded off CPU cycles vs. L1-L3 cache misses vs. RAM latency vs. sending data over the network vs. compression vs. disk latency etc, measured in nanoseconds) If you had any moderately complex new system, you'd prototype a few different approaches on a small set of sampled data, do some multiplication to figure out how much it'll actually cost in production, then compare that against the engineer time needed for various optimizations. If you were in a revenue-generating area like Search, somebody (usually at the executive level) would also be calculating how much the project was likely to make or lose for the company and ensuring that's acceptable. Not all that unlike any traditional engineering field.
The thing is that the overhead for this process really only makes sense at Google scale. For the vast majority of new software projects, revenues on success >>> developer time >>> hardware cost. So you just assume that if you can get the job done in a way that satisfies the customer, it'll be wildly profitable, and the primary factor to optimize for is developer time. And if the developer can build it, the hardware costs needed to run it will be negligible, so just buy more hardware.
This is an artifact of the software industry essentially being a gold rush, where it's rapidly eating the rest of the world and replacing non-computerized processes that are millions of times slower. When you have 6 orders of magnitude to play with, you can play fast and loose with estimates, because any acceptable solution at all will make you a lot of money. When software has eaten the rest of the world and new systems are competing with existing computerized systems, then it's worth it to start paying attention to things like efficiency, security, TCO. There's some evidence we're approaching that point, but we're not there yet, and it's still more advisable for an entrepreneur to tackle an old-school non-computerized industry than to try and improve on existing software solutions.
