Although abhorred by software makers such as most HN-readers, throwing hardware at the problem is often the fastest and cheapest way to tackle performance issues.
Especially when it indeed is "crappy software" that will take major effort to rewrite/refactor.
Hardware is cheaper than developers, and the former doesn't fail to deliver half as often as the latter...
The problem with this principle is that adding hardware tends to scale linearily at best whereas improving an algorithm sometimes buys you an orders of magnitude improvement.
Also, you need to compare the cost of a single developer who fixes innodb to the cost of hardware incurred by _all_ users of innodb who would benefit from the solution.
Adding SSD is not linear scaling. SSD has entirely different characteristics from rotational drives which in itself brings 1-3 orders of magnitude I/O performance improvement.
Trying to fit high I/O workloads on spinning disks is a lot like spending your efforts to make your program run on 64K RAM. An interesting challenge, that would surely exercise your coding skills, but would not deliver the optimal performance.
I'm not denying the benefits of SSD. I just don't think throwing hardware at a problem caused by bad algorithms is a good general principle. It may still be the best choice in a particular situation and timeframe.
Especially when it indeed is "crappy software" that will take major effort to rewrite/refactor.
Hardware is cheaper than developers, and the former doesn't fail to deliver half as often as the latter...