Hacker News Reader

Comment by jpablo | Hacker News Reader

I would choose the SSD every time over a method that requires doing a lot of consulting and engineering of the current system like Sharding.

Why spend a lot of time and work when a simple hardware upgrade will work ?

And you are deluding yourself if you think that the sharding model you are going to implement is not "only buying you time" and you will have to do additional engineering over time if you keep growing.

View on HN

It depends how many SSDs you need. If you have one hard disk that needs to be upgraded to an SSD, do that instead of spending developer time on it. However, if you have thousands of disks that would all need to be upgraded to SSDs to save your 20%, it might be worth looking into software optimization.

Same for manual cleanups and stuff. If you need to fix half a dozen source files, just wince and do it manually. If you need to fix thousands of source files, it's probably time to write a parser & refactoring browser and then use that.

> However, if you have thousands of disks that would all

> need to be upgraded to SSDs to save your 20%, it might be

> worth looking into software optimization.

However the margin is still quite high. I've replaced twice big EMC SAN arrays with 8 SSDs, and the performance gain was 300 to 400% (different customers, different applications).

SSDs envelope is usually quite narrow, but if you hit the sweet spot it's such a game changer than it beats everything else.

Unfortunately, it is very easy to see the cost of the new SSD, not so in term of manpower. I would not be surprised if many companies will choose the "more enginering" part because the bureaucracy has made this kind of tradeoff impossible to make.

This. The development department is usually a fixed cost and budgeted for while new purchases are not. SSD:s were actually quite expensive at the time, I think it cost about 10k USD or something.

Interesting.... I may be the edge case, but in my experience, the tendency is usually for the boss to be more comfortable spending money for a solution that will solve the money than burning developer time on a project that may or may not fix the problem and mare or may not be on time.

That works if you have a boss who is competent and if you don't work in big companies. That's exactly the kind of things which make small companies inherently more efficient, IMO.

Reply on news.ycombinator.com