On Software Costs

A rough trend I've detected with software licenses is the inverse correlation between size of the software's feature set and the physical size of the license metric. Features and price rise as the size of the individually licensed unit go down. At some point though, you can usually get the unlimited option for just $X more (for more fun on software pricing read Joel Splonky's Camels and Rubber Duckies post).

Nivlong's Observation of the Inverse Relationship Between Physical Size of the Software Licensing Unit and Total Cost™

I admit that I once balked at the cost of software and services for businesses (at the same time I was helping create solutions that had similarly high prices for other companies).

I've since developed the perspective that expensive business-focused software and services that solve business problems can be worth the cost (and not just because I work in software).

So let me undo the risk to my reputation and career from the above graphic with three points on software for businesses for the average corporate software user. Developers or employees in general aren't typically aware of their employer's employee-related expenses. Big software can have bigger benefits. But buying isn't always a good idea.  

I Wouldn't Pay That Much

An individual developer might find it hard to purchase an MSDN license out-of-pocket (wow, I didn't realize they were that high). Then again, individual developers don't pay developer salaries plus medical benefits (take your payroll deduction for medical insurance and multiply by about 5) and employer paid employee taxes.

Maybe that $349 refactoring tool that increases developer productivity and morale isn't such a bad deal in comparison to the costs for the actual developer?

Big Software. Bigger Benefits?

Scale this idea out to large-scale enterprise-level software and I imagine the average corporate worker couldn't imagine the amount companies pay for software. I've seen three justifications for very-expensive-software-packages.

• Benefits (not simply features, which are check boxes on a request for proposal) 
• Competitive advantage through speed of development or ability to offer something unique
• Leverage existing resources (reducing a workforce is a bad form when it's simply easier to focus on doing more with the same)

Not all benefits are quantitative and easily measured as an ROI. But it might be worth it if that seemingly-expensive-software preserves an existing workforce, lets them move from manual tasks to more strategic (and hopefully fun) parts of their job, or improves product quality and customer satisfaction.

When Not to Buy!

Despite benefits from larger software packages, there are a few situations where you don't want to buy or outsource a given feature or service.

• Core competency. If something is mission critical to your business, it might be a good idea to build it yourself.
• (Lack of) familiarity with software procurement. If the terms SOW, license agreement, and annual support costs are unfamiliar, you still might want to buy, but maybe get help or advice along the way from a method like PMBOK or PRINCE2 or a consulting/research firm.
• Confusion on the product or market space and/or business need. I'll have to save it for another blog post, but I once researched a type of software solution where each team, individual, and seller I spoke with defined the business need, terminology, license arrangements, and expectations differently.

Typical employees may not have same perspective on software costs (though do not exclude them from the same software in project implementations), but they may still benefit and appreciate when software goes right. And though I've worked on, worked with, and currently work for a company that sells software, buying isn't always a good idea.

Update Nov 20, 2012: changed the PRINCE2 link to the official site. Thanks to reader Alison for pointing it out.