How Much Is Your Productivity Worth?

I am regularly amazed at people who complain about the cost of software–especially people who make software for a living. I mean, free stuff is great, no doubt, but there are reasons that good things aren’t free, reasons that you shouldn’t want them to be free, and reasons that you should feel good about paying for good things.

The Basic Facts of Life #

The first two are intertwined. As much as we might wish things to be otherwise, living costs. In our current culture, living typically costs money. In more developed countries, living costs a lot. In and around bigger cities, it costs even more, typically. In short, most of us don’t live in a world where all our needs (and most of our wants) come free. That’s why we work and offer our time, effort, and expertise to others for money, right? I’m just saying, we have to keep these simple facts of life in view.

People who make software are people, too, that is, they have the same need to make a living. You can argue if you want about whether or not we should have anyone who makes software for a living–good luck with that. Now for the rest of us in the real world, the people who make software as anything more than a hobby need to pay the bills, eat, support the family, cover mortgages, etc. In short, in order for it to be feasible for these skilled people to make software, they need to make money.

If you like software, if you find software contributes in some meaningful way to your life–adds value–then it is in your best interests to see that the people who make it can continue to do so. That doesn’t mean you need to be altruistic and contribute to some “starving software maker” fund or anything. Far from it. It means you should be willing to return some value for the value you are getting. It means you should be willing to pay. Again, only if you find [insert name of software] valuable and beneficial. This is just common sense, and yet, the way some people complain, you’d think this was some crazy notion.

Paying for Software is Better for You #

Sure, you can try to get by on just free software–software made by people in their free time or by companies who have some other means of getting value back from you. But that only goes so far. Not every piece of software that you will find valuable can survive on those sorts of models–there just isn’t enough free time in the world, and the various free software business models only work for some contexts (and even then not all of the time).

Perhaps more importantly, by using those models you, as the user, are subject to the whims of the makers. As the saying goes–beggars can’t be choosers. So again, it is in your best interests to become a paying customer–in that relationship, you have more leverage to influence the software to become closer to what you need it to be.

The Irony of the Software Makers #

Now lets move up the pyramid a bit. Let’s assume you are a software maker of some sort–designer, developer, whatever. You are a paid professional. That means your time is quite literally money–especially if you are an independent/consultant.

Ironically, it is the indies/freelancers who often push back the most when it comes to paying for software. They might feel that “enterprises” have huge deep pockets and can afford to pay for software, but they–the poor, solitary individual–can’t. The thing is, enterprises have a lot of costs that independents don’t. And they typically have to pay for software for many people, not just one. The real difference between the two is that enterprises typically use business sense when deciding whether or not to pay–they actually consider the ROI of any given software.

Back to the issue of time is money–especially for independents. Indies really can’t afford to be ideological about this stuff. I mean, apart from the painfully obvious contradiction of being a paid/professional software maker who wants to get his or her software tools for free, there are the purely practical considerations. It’s not a question of “this should be free” but rather “is this valuable enough for me to pay for it?”.

How to Figure Out If a Software Tool Has Good ROI #

Interestingly, it’s not hard to figure out if the ROI is there for a software tool. You know how much an hour of your time is worth (H). That is your baseline. Now, estimate how much of your time will be saved by using the tool in question (T). Multiply that by your hourly rate. That gives you the total cost of ownership (TCO)–don’t forget to factor in time to test and time to maintain (fix bugs, add new capabilities, and so on). If that is less than what the tool costs (COT), then the tool has good ROI.



Okay, so there are more considerations. Like will you even be able to produce the same quality of work without the tool (Q - investment to get similar quality, if possible)? This can be harder to measure, sometimes, but it also has the potential for greatest impact. I mean, you could do A/B comparisons, but it’s hard to control enough variables. Still, you can probably use your gut and judge based on your experience.


Another consideration is on the more emotional side. Does the tool eliminate a source of pain or frustration for you? Will using the tool make you happier somehow? Happy workers are generally more productive and, well, happier. Since we’re talking about you, surely you care about your own happiness. So factor in the additional happiness, or rather, factor in the increased frustration (F) to the TCO.


Now you should be pretty well equipped to judge if a tool is worth the investment. It’s not a matter of some vague sense of “how much a tool should cost you.” It’s not a matter of “software should be free” ideologically. You’re a professional. It’s about whether or not a tool provides ROI. And now you can calculate it, more or less objectively.

Let’s do an example. Let’s say you have a tool that costs $500 per year. Your hourly rate is $65. After some estimation, you figure out that using the tool will save you 80 hours of work over a year. Depending on what it is, that may be way too low or way too high. You have to figure that out.

Using the first version of the formula:
$65*80 = $5200

$5200 - $500 = $4700

Right there, with just the basic cost formula, you already have $4700 ROI. That’s a great deal!

Now you can, optionally, factor in the quality and frustration factors, but in my experience most software tools easily pay for themselves. As an independent, I have paid for an MSDN Subscription (many moons ago). That was painful. It was like $1200, but the numbers absolutely worked out. It’s not too different from figuring ROI on hardware, too. Like I paid $1500 for a laptop to do work that will make me far more than that over time.

Factoring in the Market #

There is one consideration that may be gnawing at you. “The market.” That is, what is the current average market price for similar tools. Frankly, that doesn’t matter. See above. If the ROI is there for you, it doesn’t matter that this other tool is cheaper. As long as the ROI is there, cost is not the defining characteristic. At that point, factoring in the Q and F factors matter much more. Is Tool A going to increase your Q factor a lot compared to Tool B? Is that Tool B going to increase your F factor a lot?

For myself, if the ROI is there, I am willing to pay a bit more (if need be) to increase the quality of my output and, perhaps more importantly, reduce my frustration more. Making software is hard enough without making it harder.

The bottom line is that a professional software maker shouldn’t complain about paying for software tools that make him or her more productive, effective, and happy. We shouldn’t base our decisions on emotional sticker shock. That we can get an email provider we like for free, that we can grab some open source framework/library sometimes, or that we can use a free text editor is irrelevant. Because it’s not hard to get a good sense of the ROI of a tool. And if it is there, then it doesn’t matter if it seems expensive.

And in any case, if you are the more altruistic type, you can also feel good that you are supporting your fellow software makers. :)


Now read this

On Challenging Principles and Best Practices

Today my friend Dan Wahlin tweeted: Very interesting article: Challenging CSS Best Practices ( Agree or disagree with the suggested approach? #css The article in question published on Smashing goes into some length to... Continue →