[knorker]

Maybe.

Using actual numbers vetted by actual expenses in an actual company, if you can save 100 CPU cores by spending 3h a year keeping it optimized, then it is NOT worth it.

It is cheaper to burn CPU, even if you could spend one day a year making it max out one CPU core instead of 100.

It can be better for the business to cargo cult.

Not always. But you should remember that the point of the code is to solve a problem, at a low cost. Reducing complexity reduces engineer cost in the future and may also make things faster.

Put it this way: Would you hire someone at $300k doing nothing but optimizing your pipeline so that it takes one machine instead of one rack, or would you spend half that money (TCO over its lifetime) just buying a rack of machines?

If you wouldn't hire them to do it, then you shouldn't spend current engineers time doing it.

[inkblotuniverse]

I wasn't talking about optimization! I was talking about non-pessimization, which includes not prematurely abstracting/generalizing your code.

I've seen people making poor decisions at the outset, and having code philosophies that actively make new code 100x slower without any clear gain. Over-generalization, 100 classes and subclasses, everything is an overriden virtual method, dogmatic TDD (luckily, nobody followed that.)

The dogma was to make things more complicated and illegible, 'because SOLID'.