It is less expensive to do it inefficiently

I want to echo the "linear inefficiency, lol" meme.<p>But more importantly, the costs of inefficiency aren't clock cycles, it's the opportunity cost.<p>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.

Isn't this just a corollary of the "premature optimization is the root of all evil" quote?

<i>It takes over 800 days for the more efficient solution to gain over the less efficient one. Think about this, 800 days in which the less efficient solution is less expensive. That is two years and two months.<p>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.</i><p>This piece makes some excellent points that any start up needs to stop and take a minute to ponder.

Growth in the modern age is rarely linear. The real risk in creating an "inefficient" solution is when you've done so at the cost of extensive technical debt not just mere inefficiencies, and this technical debt blocks your ability not only to switch to an efficient solution but to stretch your inefficient solution just enough to keep your business running during periods of growth. Failing to take advantage of an order of magnitude (or more) growth opportunity can leave your company at a competitive disadvantage or even kill it outright.<p>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.

"n is usually small"<p><a href="http://en.wikipedia.org/wiki/Unix_philosophy" rel="nofollow">http://en.wikipedia.org/wiki/Unix_philosophy</a>