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


Now read this

Why does spec work still exist?

Dribbble’s position on spec work: Dribbble’s inbox is filled with requests from companies wanting to run contests that leverage the creative pool to crowdsource their product needs. We tell them about spec work and let them know it’s not... Continue →