The Economics of Software Development, Part I

This is the first post in a series on how economics helps explain the decisions we make when developing software. It is a response to “Summer School”, a series from NPR’s Planet Money.

Let’s look at two concepts from Planet Money’s “Summer School 1: Choices & Dating”: opportunity cost, and sunk-cost fallacy.

Opportunity cost

This compilation process takes a long time. I’m going to get a snack while I wait.

Opportunity cost is the cost of doing activity A instead of activity B. For example, watching another YouTube video before bed comes at the cost of finishing that novel you started last year¹.

I am reminded of opportunity cost whenever I’m waiting for webpack to rebuild a client and server in development. Every moment I spend waiting is a moment that I’m doing any development work (and a moment that I’m likely to switch to another task).

We should be attuned to these costs and advocate for the time to fix the underlying problem. If we can reduce these opportunity costs, then we can increase our productivity and even improve the developer experience.

Sunk-cost fallacy

We’ve already invested heavily in our Java architecture. Let’s find a way to make it work for this machine-learning project.

A sunk cost is one that has already been paid and cannot be recovered. The fallacy comes from making altering future decisions based on those costs.

In development, it’s common to take one of two paths: a) finding your hammer and using it for every problem, or b) chasing every new trend under the sun. Both can illustrate the sunk-cost fallacy, but the former is more straightforward.

Time spent learning a language, money spent on a subscription service, and effort spent working on a problem are all sunk costs. Once they’re gone, they’re gone. The experience can help inform future decisions, but it shouldn’t limit them with artificial constraints.