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

Using Twitter Bootstrap with Rails 3.1 and SASS

Twitter’s Bootstrap is a pretty awesome toolkit to kickstart your next web app. But it uses Less. And that’s unfortunate for the Rails community as Sass (SCSS) is pretty much defacto now. So what should we do if we want to use Bootstrap... Continue →