Thursday, November 17, 2005

Who Should Pay for Development Tools?

I work for a consulting company, and a question was posed to me yesterday about the cost of purchasing something like Red Gate. This SQL diff tool will help me deploy changes in a faster, safer way to my client's production server. So should my consulting company invest in this tool, or should my client?

In the case of the SQL diff tool, in order for the tool to work best, I need to have access to the database server that holds both the production and the development databases so I can compare them. This tool needs to get installed on my client's database server, so they need to purchase it. Should my company also purchase this tool so we can use it on other projects?

What about tools like CodeSmith? CodeSmith helps my company deliver a lower-cost and higher-quality solution to my clients, since templates can spit out our DOM library code quickly and without human typo errors that hand-cranking the code would produce. So since my client is benefiting from the tool, should my client share in or take full responsibility for the cost of the purchase?

I think that when a client needs to install a tool on their environment, they have to pay for it. I think that when the client does not need to install the tool on their environment, my company should pay for it.

The reason I feel this way is because I see these tools as investments. Tools that help my company deliver higher quality solutions quicker than our competition can, could potentially cut down on the billable hours we spend on each project. While this may seem like a loss for our company to some, I see this as giving us an edge over our competition. Today, theoretically, we could deliver an identical solution to one we provided before we had this tool at a lower cost. This lower cost, since it was attained by removing some of the manual, labor-intensive busy work, should result in higher quality. Since we removed the manual labor piece, where we get bored and are prone to make errors, we now have a higher quality solution.

I feel that this edge we now have should result in two layers of benefit. On the one hand, we should be able to win more business - even if the business we win is at a lower cost. If we can do the same things as our competitor, but for less money, we should win the business.

On the other hand, the tools should enhance our ability to attract and retain both clients and consultants. If we deliver higher quality solutions, our clients will rave about us and bring us more business in the future, right? If we don't have to spend as much time deploying, troubleshooting syntax or synchronization errors, and maintaining inconsistent code we should have more time for our consultants to spend designing, creating, and learning.

I know I may have simplified the argument a bit, but I do feel that the small investment in a tool like Red Gate's or CodeSmith should pay off exponentially. I feel that the pay off can help our clients, but in doing so, help my company even more. So I think that if a consulting company wants to remain competitive, they should welcome tools that will take the busy work out of software engineering to open the door for their consultants to invest in being innovative instead of having to invest time in bug-fixing, manual database synchronization, or the writing of repetitive code.

6 comments:

Eric Bowen said...

I feel your pain. My current (soon to be former) Minneapolis consulting company employer refuses to provide ANY tools beyond what we get for "free" as a Microsoft Gold Partner, and a laptop.

This means that I've purchased products like RedGate SQL Compare, Resharper, CodeSmith, and many others out of my own pocket... it is just not possible to "resell" the value of purchasing these to every new client I work with.

Valerie Vogt said...

Eric-

Are you leaving your Minneapolis consulting company because of thier lack of interest in investing in tools such as these? Do you feel that your new employer has a better approach?

I am just curious how valuable other engineers feel these tools are, and if you feel that your company would have made a move towards retaining you if they had shown a willingness to invest in more tools.

Avonelle said...

I think the question of "who pays for it" is really separate from "who owns it". If the tool has to be installed on the client's computers, then they will likely both pay for it and own it. But if the tool is installed on developer computers, things get more murky. The consulting firm might own the tool, but the cost is likely passed onto the customer anyway, either directly or indirectly.

When I worked for a consulting firm, I got to the point where I was buying almost all of my own hardware/software. Then I didn't have to waste effort trying to convince a bean-counter of the value of a tool, and I knew I could keep using it even if I left the company. Also, it fits more cleanly with the reality of many such tools, which is that they often require a certain amount of time/effort to use effectively. It is fine to say that the consulting firm "owns" the software, but the reality is that unless someone else becomes familiar in its use, that tool will probably never be used again except by me. So, it may as well be mine.

Eric Bowen said...

My decision isn't based on a single factor. But this issue demonstrates a major philosophical difference between me and my soon to be former employer.

Do you empower your employees to make business decisions, or do you treat them like mindless children (aka "resources")?

For instance: I believe that spending $250 dollars on product X would significantly add to my ability to deliver a quality solution for my client, and in turn generate more revenue for the company... do I have the "empowerment" to make a decision like that, or at a minimum, do I have the option to make a business proposal to somebody that is empowered to make that decision… or is there a collection of blanket policies that rule out any such options?

This basic concept can be applied to other aspects of the consulting business (sales and account management issues come to mind as recent pain points).

Bottom line: If you treat you employees like mushrooms ("Keep them in the dark, and feed them crap.") they will eventually get frustrated and leave...

Jake Good said...

That is crazy! I just sent an email to someone with purchase power about buying CodeSmith for myself and a few of my team members.

I definitely think that the company should buy the tools necessary to provide the best software for the client.

As far as CodeSmith is concerned, great tool. We have a developer entering the project after it's start over 2 years ago. There are lots of CodeSmith templates that make our development on the project go fast and it would allow him to have a fool proof entry to the project and not feel affraid of doing something wrong or out of our project standards...

mork said...

Val... I quickly felt that same unwillingness to pay for tools.

I recommend you use your tech allowance to buy the tools. More than half of my tech allowance this year was spent on tools that directly benefit the company and the customer. The good thing about it, however, is that when you find a company that has a sensible philosophy you can take the tools with you when you quit.

Eric, I would suggest not applying at Val's place of employment. Knowing both companies quite well I think you'd be even more disappointed.