It is less expensive to do it inefficiently
ayende.com
ayende.com
But more importantly, the costs of inefficiency aren't clock cycles, it's the opportunity cost.
It depends on the situation, obviously, but inefficiencies can have a very real cost in terms of lost sales or customer dissatisfaction. The ROI will vary on a multitude of variables, but that's my point: these graphs simply don't reveal the complexity of costing models that really come in to play.
Let us plug in more realistic numbers for the cost of labor, shall we? Let us say that the labor cost is 80$ per hour (which is still cheap). At that point, it would take close to 5 years.
This piece makes some excellent points that any start up needs to stop and take a minute to ponder.
The biggest concern I have is that he account nowhere for growth of that new feature, and the increasing hosting costs as a result of that growth. Part of efficiency is how fast is it now; the other half of efficiency is how will the performance change based upon an increased load.
Part of the risk of putting out a new feature is you don't entirely know what the uptake will be. It could fall flat, it could grow exponentially within the first week. Or, as this author assumes, it could enjoy a rapid uptake of a certain amount, and then level off just as quickly. I'd argue this last possibility is almost never the observed pattern.
The other part of the risk is that, if you go the inefficient route, you may not have the time later on to even build bad hacks within the inefficient code to make it speedier. This is a bad situation to be in, you end up getting screwed by your own unexpected success, and users get pissed because now your site is unreliable.
Yes, spending insane amounts of time on efficiencies probably aren't worth it. Yes, you need to do cost-benefit analysis to decide what amount of time is. My point is that there is a lot more to consider than the author gives credit for, and I don't think you are as likely as he believes to reach the same conclusion he did. Cash flow is important, but it is also important to remember that things don't remain flat or grow linearly just because you assert that they do.
Thanks for your very well-thought out and meaty comments.
Recently I decided to take the time to make our system configuration for a new user really easy (I was doing it by hand in a slow way before) because I know that once we have many users I won't have the time to fix the admin interface around the time demands of doing it by hand.
There are lots of decisions where you don't know up front the cost of an inefficient solution - perhaps the feature is underused and it doesn't matter - you've wasted time making it fast. Perhaps you become a success overnight because of the feature but now your server is fried. It is a tough call - either way, you should spend some time thinking about how you would throw more hardware at the problem should it arise.
Gridspy is still pretty tiny load wise, but I have put a lot of thought into scaling plans, keeping my options open.
So build an inefficient system if you think it's a better solution in the short-term. But be careful that you know the difference between mere inefficiency and a horrible, grotty, dailywtf level hack-job that may seriously limit your company's future.
It's the difference between choosing not to use a steel beam for support and using a wooden beam on the one hand or using a step ladder sitting on top of a stack of half a dozen phone books. One is still sound engineering, but not suitable for higher loads in the future, the other is just a mistake waiting to come back to bite you in the future and isn't even suitable for the task at hand.