+972 52-548-6969
Tools matter
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.
Comments
This is the age-old "hard costs, soft returns" situation where the investment represents a hard, measurable, concrete value (the cost of the tool) but the return is soft, hard to measure, and nebulous to defend (the labor-savings).
In any such situation, it takes an enlightened manager to recognize that soft costs (salaries in this example) are actually still costs just as real as hard costs; in my experience if you don't start with this premise accepted by management then no amount of the kind of math you are demonstrating here will successfully sway them to invest in the tooling, no matter how well the formulas show ROI :)
Bah, most of the companies I've worked at give their developers business user machines. I think the piece of crap I'm running with now is a 2.0ghz P4-D with 2 gigs of RAM and a 5400 rpm laptop drive in a slim profile desktop.
If they can't spend an extra $250 to buy a better desktop, you think they're going to spend $2000 for tools?
And it's amazing, senior developers in our market bill at least at $100/hour. Back in 2005 the developers in our group all had laptops which took a good 30 minutes to reboot or compile the full solution. It's a bit better now, just because I don't think you can buy a machine that slow anymore. if you could, management would do it to save a couple of bucks.
Make this count.
Push a mail to the bean counter, with numbers.
This is how I doubled my laptop performance: http://www.ayende.com/Blog/archive/2006/06/13/7497.aspx
The price comes in a bit high for the casual developer, and larger teams. $2000 would be my tool budget for most everything I need, but I have 12 other developers, and most of those tools would be needed there as well. And who knows what happens when we add a thirteenth, or someone gets reassigned and we have to transition the licenses to a new dev! So we end up around $24000 for the team. Sure, some don't need this or that, but they need something else, so It ends up around the same.
When I'm doing casual development at home, I can't afford to shell out that much money. Sure, it's the cost of a decent computer, but it is recurring, has FAR fewer uses (unless programming X or Y app that needs it all is my only hobby), and needs to be renewed! And I'm not making any money off it.
Either way, .Net components and tools are just generally overpriced. R# costs only moderately less than their entire Java IDE, doesn't do as much (and is buggy as hell), and you have to buy VS.Net too :( TDD wants money, typemock wants money, everybody wants money. It's not a bad thing, but it seems like the standard has been set that everything costs ~$300 on average, which is sad. DevExpress is an exception (we do winforms), since they are reasonably priced and easily worth the $, but I still can't afford them for hobby use.
For instance, we like the tool "CodeIt.Right", but it is now $250 per seat. We will be buying ONE copy now, but when it was looking like $100 per seat or less we were going to get it for everyone on the team. Thats a marketing decision, I suppose.
Well, I'll wrap up with... do we get lots of overpriced (but quite nice) components and no integration support from MS, or lots of crappy components (or none at all), but with great IDE support in Java. I guess it depends on how much money you have lying around doing nothing.
You're absolutely right. The argument against tools in my experience has more to do with people not wanting to take the effort to find out they exist and learn how to use them. Very few people actually do development in Notepad - evidence that to some extent, everybody agrees tools are important
Generally speaking, I agree with you. Quibbling about the cost of quality tools when compared with the cost of quality developers is idiotic, and yet all too prevalent.
But I have to disagree about Resharper. I tested version 3 last year and version 4 a few weeks ago, and although it has many useful features, it is just too unbearably slow. Add that to an IDE that is already less than zippy, and my productivity went down the tubes. The problem is not my machine, either; I am in a relatively enlightened company that understands that developers need a lot more beef than the average business user. And I'm not talking about minor things; in some cases I had to wait several seconds for a few lines of text to appear after I stopped typing. In an IDE, the letter that I type should appear instantly (duh); anything less is unacceptable.
Its unfortunate, because I can easily see how many of the features could have saved me a lot of time. But when I have to wait to see the code that I have just typed, its not worth it.
Tools are quite often understimated. I heard of many person telling that they can program well even without resharper, it is true, but many people, after a try of R#, tells me..."hey, I cannot live without R# now" :D
Tools like SQL compare not only can save you an enormous amount of time, but helps not to commit mistake. We have in production several site, and the developement is alwais on. I really cannot think to make a deploy in a release machine without the SQL Compare tool, that shows me exactly what is changed from the version in the release machine and the one on the dev machine. does it wort 400$, definitively yes.
Quite often I saw people being bites by attitude like: "Hey, this simple ritch text editor cost 1000$...no no no, we do not have the budget, let one of our developer write one". After a couple of weeks we have a prototype of the editor, but with a little set of features, after a month the manager decide to buy the commercial one..........
alk.
David Nelson, how many lines of code in the file you're editing?
It's got to be something with either your machine or the amount of code in a single file/solution, because no one I know has this problem with ReSharper (4 )- unless there's more 3000+ lines of code in one file. (which should never happen IMHO)
@PandaWood
The worst offender is ~4100 lines. Several files are 3000+. Most are in the 500-2000 range.
Its fine for you to say that files shouldn't be that large, and I would agree with you in an ideal situation. But I am part of a team maintaining a legacy code base. My goal was to use Resharper to help me start refactoring that code base, and once I proved that it could be useful I could introduce it to my team. But I couldn't even get started because the whole IDE became unresponsive.
And frankly, I don't see what difference file size should make to this issue. I can see where a large file might take longer to open, if there is initial parsing going on and what have you, but once the file is open there is no reason for every character I type to take a second or more to appear.
I agree 110%
http://ferventcoder.com/archive/2008/09/07/tools-matter-automated-builds--automated-deployments.aspx
Comment preview