Breaking The Wheel

The Fallacy of “Free”

Cost is often a significant factor in project management – which is as it should be. But, much like using weight as your only measure of fitness, monetary cost in and of itself is not sufficient for proper decision making. You also need to consider the less obvious costs (and savings) of your decisions.

By Reading This Post, You Will Learn:

  • Why you need to think about what a decision saves, not just what it costs
  • Why you also need to consider what something costs, not just what it saves
  • How supposedly “free” software can impose expensive costs elsewhere in your processes
  • Why thinking you can save money by developing expertise in-house rather than hiring experts is short-sighted

Don’t Just Ask What It Costs, Ask What It Saves

Should you spring for a higher end development PC? A robust build server? A full-featured Wacom tablet? Multiple monitors for each team member?

Running is a business is expensive, particularly a technology-centric one. But before you balk at prices, understand that a investment that appears expensive on first glance may end up paying for itself.

For instance, your team members might not fully appreciate the cost of running a studio, but they damn sure will appreciate an efficient workflow. Strange as it may seem, professionals like being treated like professionals, including having access to professional-grade work stations. A higher-end PC and industry standard software may be more expensive than other routes available to you, but they will help reduce time lost to technical issues, allow new team members (who are likely accustomed to industry-standard tools) to get up to speed faster, and will reduce the frustrations that inevitably cause expensive talent drains.

Or, to take another example, establishing a continuous integration server is a cost you might be attempted to forgo. They can get expensive after all. But, a continuous integration server 1) takes the burden of pushing builds off of developers’ shoulders, which becomes increasingly valuable as builds get larger 2) gives all team members a central point from which to pull builds and 3) makes debugging broken builds easier (for changes per build means fewer suspect merges to review).

Don’t Just Ask What It Saves, Ask What It Costs

The inverse analysis is just as applicable. You might save some scratch by buying lower quality development computer. But those savings will be eaten alive in wasted dev-hours if your team members have to routinely reboot their machines. If you’re not willing to pay for robust version-control, be prepared to squander a pile of time figuring out if the bug you’re seeing is the code stored in GitHub or larger file size assets stored in Dropbox.

In short, basing efficiency decisions purely on monetary savings is asking for a death by a thousand cuts. All those reboots, all the searching, all the finagling with featured-deprived software. Sure, any one instance of it only takes a few seconds or minutes to resolve. But compound those instances over the length of a project…and you’ve squandered days or weeks of productivity. Then, add the frustration these inefficiencies induce on you team members – making them both less productive and more likely to search for employment elsewhere – and the costs sky-rocket.

The point I’m making is not to spend money hand-over-fist or ignore budget constraints. But consider the monetary savings you are trying to achieve in the context of the non-monetary costs you’re inducing. Some of those costs might make the savings a net negative.

“Free” Software

The free software trap snags a lot of teams. Why pay for Jira or Hansoft when Trello and Google Docs are free? I don’t need 3D Studio Max, because Blender is open source. If I use Google Drive, Drop Box, and Box together I don’t have to pay for storage space. I don’t need a to pay for a build server – I can just push locally and share manually.

This phenomenon is best summarized in the timeless phrase “Penny wise, but pound foolish.” You’re putting a premium on cash, but failing to put a proper value on time.

What inevitably happens is that these same teams have to come up with all sorts of bastardized, hodgepodged, ad-hoc workarounds for the limitations of free software. Workarounds that inevitably induce uncertainty and inefficiency on processes. And those inefficiencies cost more in terms of wasted time than using the free software saved in the first place.

And when it comes to open-source software, a friend of mine puts it best: “Open-source tools are only free if your time is worthless.”

Training Versus Expertise

Another common mistake companies and managers often make is to eschew hiring or contracting experts in favor of figuring out a problem for themselves. The notion has some logic: hiring people (as internal employees or professional consultants) is very expensive. We can save that money by solving the problem ourselves.

This is painfully shortsighted.

Modern technology has made it almost trivial to quickly acquire information. But information is not the same thing as expertise. Anyone can take a certification course, attend a seminar, or read a cutting-edge book. In other words, anyone can buy training.

Expertise, on the other hand cannot be bought. It can only be hired* or developed.

My favorite definition of the term “expert” comes from the immortal Niels Bohr: “An expert is a man who has made all the mistakes which can be made, in a narrow field.”

Translation: if you want to build your own internal expertise without paying outside experts, you will have to make those mistakes yourself. And that’ll cost you: time, wasted effort, and inefficiencies.

The above does not make training “bad” and paying for expertise “good’ – one is not better than the other. My point is that both carry a cost. Your job as a manager will be to decide which bullet you want to bite: time and mistakes or money spent.

Further Reading If You Enjoyed This Post

Bottlenecks and Hindsight: Why Auteurs Make Horrible Economists

The Time Value of Fixes, Or: A Fix in the Hand is Worth Two in the Bush

The Law of One Price – A Business School Mini-Lesson


H.L. Mencken once said “For every complex problem, there is an answer that is clear, simple, and wrong.” Making operational decisions purely on cost-based metrics, without considering efficiencies and other second-order effects is asking for a world of trouble. Think through the impacts of your decisions and you may realize decisions designed to save money may cost more then they’re worth.

Key Takeaways

  • It is not sufficient to consider what an investment or expense costs without considering what it might save
  • Likewise, don’t consider what a decisions saves without pondering what it might cost
  • “Free” software isn’t free
  • You may save money by developing (rather than hiring) expertise, but you’ll also make expensive and time-consuming mistakes along the way

*Okay, yes, you can buy a company with a particular expertise…but you’ll still need to retain its staff to access that knowledge. In other words, you’ll need to hire all of those new employees and put them on your payroll.

If You Enjoyed This Post, Please Share It!

Creative Commons License
“The Fallacy of Free” by Justin Fischer is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.





Leave a Reply

%d bloggers like this: