It is less expensive to do it inefficiently!

time to read 6 min | 1026 words

This is a continuation of a twitter conversation that I had with Karl Seguin.





One of the problems for developers is that we tend to have a hard time distinguishing between the right thing from a technical perspective and the right thing from a business perspective.

One of the known issues with the profiler from the very start was the how to handle large amount of data. The profiler use to keep all data in-memory, which put a hard limit to how much data it can manage. The right solution would have been to build persistence into the profiler from the get-go. It would eliminate an entire class of problems, after all, and we knew that we would have to get there in the end.

It is also, quite incidentally, the wrong decision to make. By keeping everything in memory, we significantly reduced the complexity that we had to deal with during the development of the profiler. It let us concentrate on getting features out the door and get to the point where people actually pay for it.

That decision has later cost me about two weeks of complex coding, and I would do it again in a heartbeat. One very important thing to remember is that in a project, every action that you take has a certain ROI value. Spending those two weeks earlier in the game would mean that I wouldn’t be able to provide as much features, get the required feedback and actually get some money in so we could continue development.

Of special interest are those comments:



The problem with this approach is that it makes an erroneous assumption, that your time is free. This is erroneous assumption because even if you don’t pay yourself, your time represent an opportunity cost to implement some other feature.

Let us try playing with Karl’s number for a minute, okay? Let us take a low end outsourcing hourly rate as our example, 20$ per hour.

We have two solutions in front of us, one will take about a week to develop, but would be three times less efficient than the alternative, which would take four weeks to develop. Remember, in most cases, the inefficient solution is simpler. It takes a lot of thought and sometimes complexity to figure out how to do something in the most efficient way possible.

In both cases, we are talking about a two men team, so the total cost for the first solution is 2x40x20$ = 1,600$, which the cost for the second one is 6,400$. The difference is 4,800$. That is a lot of money.

Amazon EC2 Double Extra Large costs (sounds like a McDonlands order, doesn’t it?) are:

  • 1.20$ / hour – Linux
  • 1.44$ / hour – Windows

We will use the Windows number, since it is higher, and let us see what the results are. In the first solution, we consume 6 hours per day for this feature. Using the second one, we consume 2 hours per day. Let us plot the numbers over a period of two months, shall we?


This is a true no brainer, right? The more efficient solution (blue) handily thumps the  less efficient (red) one. But what happens when we factor in the development cost?


Now the story looks far different, right?

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.

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.

Nitpicker corner:

  • The inefficient solution has to be adequate, of course, if it isn’t, it isn’t considered.
  • Even if the inefficient solution is an order of magnitude worse than the efficient one, it will still be cheaper for a year!
  • Yes, I am ignoring the refactoring cost:
    • Inefficient – 1 week
    • Efficient – 4 weeks
    • Inefficient now, refactoring in a year – 1 week now, 7 weeks in a year.

That would look something like this:


But, and this is important, after a year, we know whatever we:

  • actually need it?
  • can afford it?

I would choose the inefficient solution every time.

In other words, we have technical debt vs. monetary debt and time debt here. And in most cases, getting to the point when you have a cash flow is the most significant target you should approach.