Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Performance isn't a problem until it is, and then when it is a problem, it's bigger than any other problem in the world because you have nothing to sell if it does not operate.

I always thought I was being wise by not doing any premature optimization, but after a few lessons learned the hard way I certainly factor in performance to the design of software before I build now.

Scalability is not a "feature" tacked on at the end development.



Scaling will only become a problem when/if you achieve product/market fit.

What percentage of startups on HN have achieved product/market fit, are past a 128GB commodity box AND have no dedicated engineering team for scaling issues?


As an engineer, not knowing how to scale when working on something that may need to scale could spell the downfall of whatever product you're working on. Yes, all is well and fine until you hit a natural growth cycle and can't commission new boxes fast enough because each request is taking 300ms. Your database isn't accepting enough requests (plus, some of your bad queries that aren't indexing are blocking too long). Then your web servers run out of memory because you are using an ORM for large lists of items that you're just returning as an array...

Once you get to the point of no return you have to know what to do or you'll suffer. Learning that when fire is falling from the skies is the worst way in retrospect.


Part of being a good developer is knowing where the scalability bottlenecks are likely to be as you are developing software, and making intelligent decisions about the algorithms, data structures, and architectures you use. I would never advise a developer to not "factor in" performance or future scalability needs at all. The problem is when you spend significant extra effort building highly scalable architectures that you don't need now and may (likely) never need.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: