The Economics Of Productivity Tools In Software Development

David O’Hara, one of my colleagues at Improving Enterprises, posted the following to Twitter today:

Folks, if you’re not willing to buy tools to get your job done faster/better – please do us all a favor…

He and I had the related Twitter discussion which you can follow, as well as a chat offline to further clarify what we meant. However, I thought it was a subject rich enough to deserve more than 140 characters in explanation. It’s my stance that the quote above at first read is essentially saying if you aren’t willing to buy productivity tools, then we’d be better off without you. David has since explained that he was really targeting people who complained about built in tool support or the lack thereof and that if you weren’t willing to buy the tools, stop complaining and just do your job. However, several other people agreed with Dave’s quote as written and I fairly strongly disagree so let’s look at the quote as it is.

My stance is that this is a purely economic decision at its most core, one that if taken at face value, expects developers to take a financial risk, e.g. pay for a yearly subscription to Code Rush or Resharper, and accept in return a non-financial reward, e.g. greater productivity which we’ll assume leads to greater happiness. Additionally, an employer who can convince all his employees to buy their own subscription reaps almost immediate rewards while taking on none of the risk. This is a bad economic decision for an employee to take. There is an edge case which nearly everyone brought up in their agreement with David and that is a craftsman. We’ll discuss that in a minute.

One point that’s critical here is that we’re talking about salaried employees and not independent contractors of any kind. When I first objected to Dave’s remark, I questioned what other profession expects the employees to buy their own productivity tools. I don’t think there are any outside of independent contractors. This is an important distinction because contractors can pass the cost of their increased productivity on to the consumer through either higher prices or longer engagements if they choose not to use the productivity tools. Salaried employees do not have that option. Several people argued that employees who were more productive would be rewarded in the long run but again, this is not a good economic bargain since future returns on my economic risk today are inherently, well, risky. Maybe the employer lays me off or pays me less than my productivity cost me.

Looking at it from another angle, by convincing me either implicitly or explicitly to pay for tools to increase my productivity, my employer has also lowered his salary costs while gaining in output. Again, in an economic agreement, this is a big loss for me. Of course, David didn’t mention the employer in all this but the assumption is that if I have to pay for my productivity tools, it’s because my employer refuses to do so for whatever reason.

Granted, I may have a choice in the matter. I may choose not to work with the tools. I may choose to get another job. But all of these come with associated costs, costs that must be weighed when making a decision.

In the end, the best employers ought to provide the best tools for their developers in an attempt to get the very best employees. The best employers do this because they know it’s in their best interest to focus on the long term return of having the very best employees while the worst employers focus on the near term return of the cutting costs. This is true across many fields, not just software development.

What about that edge case? Here’s where my thinking converges with David’s sentiment. Craftsmen always work with the best tools because their work is qualitatively different than that of the average software developer. They want to operate at the highest level of efficiency in order to achieve the quality of work that their internal motivation demands. Of course, the irony in this is that typically craftsmen refuse to work for employers who expect them to buy their own tools because that is a sign of the type of work or environment they can expect.

Overall, I don’t think it should be the employee’s obligation to provide themselves with productivity tools. They agree to do a job to the best of their abilities when they join a company. If there are tools that enhance their abilities, the employer should provide them as an investment in the long term gain of more productive and ultimately happier employees.

Of course, all this said, I choose to buy my own tools. I do this in part because I want to have them after I leave a given company but also so that I can use them in my own personal development as a software developer. I’m light years away from being a craftsman but I suppose striving to be one is the next best thing.

2 comments on “The Economics Of Productivity Tools In Software Development

  1. Ok, so a couple of points…
    I would argue that the use of the term “productivity tool” is a crutch in this argument. They are all tools that we use to get the job done. Period. To give you a comparison, a mechanic doesn’t call an impact driver a “productivity tool” although, by the definition we’re using, that’s exactly what it is. He could certainly get the job done without it but it’s the right tool for the job and so he gets one.

    Which brings me to my next point, a mechanic is an excellent example of a non-contractor who is required to provide their own tools. My brother had to drop several thousands of dollars when he joined Volkswagen just to get his toolbox up to par and he continues to add to it on a regular basis. It’s the cost of being employed. He will also take those tools with him when he leaves which is on par with us taking our tools with us when we leave so I don’t think you can say there is a financial burden with no benefit. You bought the tool, it’s yours and you got what you paid for. I’m on the fence about the whole productivity as the only benefit thing as well. If you can get your job done and go home on time, that’s not just productivity. If you don’t have to work on Saturday to figure out why the Friday deploy has hosed the production server, that’s not just productivity. Yes, my assumption is that these tools will lead to better code, less defects, etc. but I don’t know that it’s very far off. I know that using the right box end wrench means I’m less likely to strip the nut or beat up my knuckles so that might translate…or I might have just taken the analogy too far.

    Like we discussed, my initial tweet was targeted at the whiners and I stand by that. However since we’ve been chatting and I’ve been pondering, I feel that you’ve talked me into my new position of “It’s your job and you should be willing to throw down”. If you’re not, what are you doing here? Go find something you ARE passionate enough about that you would be willing to pay for it and do that. That said, I can’t agree enough with you regarding a company that isn’t willing to pay for tools or that would be so parasitic as to knowingly benefit from pushing the costs off on to employees – but that’s a whole different discussion.

  2. Niklaus Wirth's Ghost

    November 12, 2009 at 8:43 am Reply

    You ought to get a blog instead of wasting time in my comment section. 🙂

    If they are all *just* tools, why do we expect our employers to provide Visual Studio but not Resharper? Microsoft Office but not UltraEdit? A computer but not 2 extra monitors? I think there is a clear distinction in the tools we are discussing. Any employer who hired a Microsoft developer without providing Visual Studio would find themselves without employees. As far as I know, we’re talking about tools that are far outside the realm of required but that increase productivity.

    I’m not aware of mechanics having to buy their own tools. Are the tools specific to particular kinds of cars? Are the mechanics salaried employees? It’s an interesting example I’ll have to think about though my initial reaction is that it’s an exception that proves the rule.

    I never said there is a financial burden with no benefit. I said that the benefits are non-financial. My entire (poorly argued) argument is that developers who have to buy their own tools (specifically productivity tools) are taking on financial risk with no short or medium term financial return while the employer is doing the exact opposite, a situation that I find problematic since it’s the employer who should be investing in the future more than the employee. After all, an employee can just go get another job. An employer can’t just go get another business.

    It’s nice to dream about everyone following their passion but in reality, that’s not feasible. Maybe I’m a cynic but we’re a long ways away from everyone being able to choose what they love to do. Like Judge Smails said “The world needs ditch diggers too.” This is probably an entire blog post but I wrote some basic thoughts on it when Jay Fields said 50% of all developers should quit and find a new career. I think your stance is similar to that. It’s dismissive of all the reasons someone might choose or have to have a job. I’m sure passion is nice but it isn’t sufficient to pay the bills.

    Looks like I need to get a blog too.

Leave a Reply

Your email address will not be published. Required fields are marked *