Tools matter

time to read 4 min | 649 words

A few hours ago I responded to a mail message that had:

The scenic route is also the poor-man's route...
Pushing a Typemock purchase at the current state of things won't bear any fruit.

I have run into similar sentiments with regards to ReSharper, dotTrace, RedGate's SQL Compare, etc.

I am not sure how to respond to such a statement, because it the underlying assumptions are all wrong. Let us do the math.

TypeMock (enterprise) costs 500$. That is the most expensive version they have (although if you ask nicely, I am pretty sure they will agree to raise the price). Resharper is 350$ for the VB & C# edition, and just 250$ for the C# edition. dotTrace is 500$, and SQL Compare is 400$.

So you need a 500$ tool, or 2000$ set of tools, or something of this order.

What is the ROI of that?

I hit oDesk in order to get some estimates about outsourced costs. It seems that at the high end, in oDesk, you can get a C# dev for around 60$ an hour, but the common rate is something around 20$ an hour.

None of those tools is really mandatory. With a bit of work, you can get things working without them. But that bit of work is expensive.

Taking SQL Compare as an example, it costs 400$. Without it, you are forced to spent time maintaining alter scripts, find out that Joe forgot to checkin the latest script so it is now breaking in QA, etc. Using the common outsource rate as a metric, SQL Compare would cover itself if it would save 2.5 days. From experience with projects that did manual schema management, it takes a lot more than that over the life time of a project.

R# saves a lot of time. It saves it in tiny increments, so it is sometimes not noticeable, but it does. Using the outsource rate again, it would pay for itself by saving a day and a half. I write software 3 to 5 times faster when I have R# than without it. It would be a steal for triple the price (but don't tell JetBrains that).

Trying to put a legacy system under test without TypeMock is possible, but you are going to spend a whole lot more than the 3 days it takes to pay it back. And this math is stupid! I am taking the low end of the pool. If we will take the 60$ an hour, which is more reasonable it takes just a day to see the ROI of any of those tools.

Tools matter, a lot. And we need to consider the moral effects as well. Another big productivity enhancer.

Now, tools aren't silver bullets. You should evaluate a tool to see its worth, absolutely, and there are some tools that may be valuable in one scenario and worthless in the other. But if you believe that a tool will save you time and effort, just do the math. It is usually worth it.

So, given that this math is trivial, why do so many organizations choose the stupid approach? The answer is quite simple, budget.

A department has a budget of 100$. But usually it is not a budget of 100$ outright. It tends to be things like, 85$ allocated to X, 10$ allocated to Y, etc. Salaries are not included in most budgets. Headcount does, but the salary is not something that is usually within a particular department. So given that a salary is fixed and usually outside the direct control of the department, the worth of a time for employees tends to be dismissed. That is already budgeted for, after al, and outside my control. Buying a tool, however, comes out of my budget, which is a problem.

This is the story of trying to achieve local optimum by harming the organization as a whole in all its glory.