[jrockway]

Is programming time expensive?

Let's say you have a mobile app used by 1 billion people every day. It sounds crazy, but I bet a fair number of people in this forum contribute to such an application.

Imagine you want to make an optimization that increases battery life by 1%. Assume a 30Wh battery and that it's charged once per day. Over the two year lifetime of the phone, at $0.10 per KWh, that change would save your users 21.9 million dollars in aggregate. Even with a team of 40 people making $500,000 per year working for a year, you still increase the efficiency of society with that change!

(I know, this ignores the opportunity cost of adding a new feature before your competitor, or focusing on something that will bring more user happiness, or the externality that users don't notice the $0.00003 they're paying to supply your app with electricity. But the point is, we have a lot of power, and our time is much cheaper when multiplied proportionally to that impact.)

[corysama]

Similarly, my general rule for optimization is: Add up all the time that will ever be spent waiting on this code by all users ever. If that's less than the time required to implement the optimization, don't bother.

That eliminates a surprising number of tempting gold-plating situations that occur in rarely-executed code.

On the other hand, cutting 1 second of wait from a million daily active users adds up to whole human lifetimes saved rather quickly.

[lifeisstillgood]

The usual (and frankly convincing) argument is that you won't get to a billion users without using the cruft as a means of scaffolding to help change and iterate and try new features, whatever the behind the scenes architecture looks like

Then, when you have 100 million users, you can afford a team of optimisation specialists to strip out that 1% battery life

But yes, it seems on average npm pulls in 1,000 upstream packages when you just try making a vanilla project of any complexity