Don’t Prematurely Optimize

When performance wasn’t a consideration from day one, inefficiency becomes endemic, corrupting every square mibbibyte of the project. Why not iterate a giant array instead of using hashes? Why not use LINQ everywhere, repeatedly and inefficiently filtering a massively excessive superset of the needed data?

Source: Yafla

I disagree.

Firstly, I feel that the array vs hash and LINQ examples are fairly contrived. In reality, a good engineer shouldn’t even consider those approaches in the first place. There’s rarely a compelling reason to do so.

A decent solution of either example would take marginally more time and produce way better code. And that’s a trade-off a good engineer makes in a heartbeat from experience.

Engineering is about making business goals/optimization trade-off decisions. Constantly. One of the many traits of good engineers is how quickly and accurately (on hindsight) we can make such decisions. Unless the business goal is optimization.

I find that these debates often come down to an either-or proposition: “put off optimization indefinitely” or “optimize to the max the whole way through.” But it should never be so black and white. From a business view, both approaches are wrong, as they tend to entail unnecessary costs.

After much programming experience, including trying both extremes, I’ve learned that a middle road is the most cost-effective.

-Jarret on Hacker News