You've probably heard both sides of this argument: throw hardware at performance problems, no no, improve the code. Jeff Atwood at Coding Horror comes down on the "more hardware" side in this post:
Coding Horror: Hardware is Cheap, Programmers are Expensive
Usually I agree with Jeff, but I don't agree with his thesis here. The commenters on this page present some good convincing counterarguments and examples that tuning or modifying algorithms can be very cost-effective.
But sometimes I do like to throw hardware at a performance problem. Wait, haven't I just contradicted myself?
It's all in the context and the human elements. Let's consider the possibilities:
- You're in charge, you make the decision. Obviously, you'll consider all the pros and cons and make the right choice. Sometimes the right choice for return on investment is to beef up the hardware, sometimes it's to tune the code, change the algorithm.
- Someone else is making the decision, and they're just like you, or they always listen to your good advice. Again, sometimes the choice will go one way, sometimes another, but probably the right path will present itself.
- Someone else is making the decision, and they always prefer one approach or the other. Sometimes they'll make the right choice, sometimes the wrong one. Plenty of examples of both in the article comments.
- Someone else is making the decision, and they are open to either approach, but they don't have enough information to make an informed decision. For example, they may not know the price/performance of available hardware, or may not know the code base or the team's coding skills well enough to estimate the potential for improvement vs. the time involved.
If all situations were equally likely, we could say don't worry, a majority of the time it'll turn out OK. In the real world, scenarios 3 and 4 occur more often than you might like. You'll need to have strong arguments for "more hardware" and "more tuning" at the ready at all times, not just have one dictum for all situations.
2 comments:
a good point about buying hardware is that you do not need to change the code :)
I've been on both sides of this issue. Once I was called in to "tune Oracle". Oracle wasn't the problem - the application was running fine on the local network. Performance went to hell when they tried to add users who were connecting on a WAN. While I did make a few suggestions about changing the application to minimize round trips to the database, I also brought in a network engineer to do some diagnostics on the WAN. He recommended a major upgrade of the WAN and proved that WAN was the problem. The customer said "no can do" and were upset that I had not "tuned Oracle" as they wanted. We took the money for work already completed, and said "good luck with that".
Post a Comment