Skip to content

Software Is Economics

Most arguments about software are really arguments about economics dressed up in technical language. "We should rewrite this." "We need to refactor before we add the new feature." "We should buy this, not build it." Underneath each of these is a claim about cost, value, and uncertainty.

Treating software engineering as economic decision-making, rather than as craft, art, or pure problem-solving, changes both the conversations and the outcomes.

Every Decision Has Five Costs

Any meaningful technical choice has at least five costs, and the most expensive ones are usually invisible at the moment of decision.

  • Implementation cost. The labor and time to actually build the thing. This is the only cost most planning conversations track. It is almost never the largest cost.
  • Operational cost. What it costs to run the system once built: hosting, licensing, monitoring, on-call rotations, support tickets, vendor contracts. Operational cost continues for as long as the system exists.
  • Maintenance cost. Keeping software working as the world around it changes. Frameworks deprecate. Libraries publish security patches. Browsers update. The business pivots. Even systems no one is actively "improving" require steady investment to remain functional.
  • Opportunity cost. What the team is not doing while they are doing this. Every project funded is several projects unfunded. This is the cost that has no line item in a budget but routinely dwarfs the others.
  • Complexity cost. The cognitive overhead a decision adds to every future decision. A new service, a new vendor integration, or a clever abstraction becomes context that every subsequent change has to reason about. Complexity compounds.

The cheapest decision measured in implementation cost alone is frequently the most expensive once the other four are tallied. Organizations stuck in the build trap routinely tally only the first cost, because their incentives reward shipping rather than stewarding what has already been shipped.

Uncertainty Is the Defining Constraint

Software economics is not manufacturing economics. A factory producing a million identical widgets can predict cost, quality, and yield within a narrow margin. A software team has not built this exact system before, will not build it again, does not know how users will actually behave once it ships, and does not know how the business will look eighteen months from now.

This uncertainty is not a flaw in the planning process to be eliminated with more requirements gathering. It is the irreducible nature of the work.12

Decisions should therefore be evaluated on more than expected outcome:

  • Reversibility. How easy is it to back out of this choice when we learn something new? Reversible decisions can be made quickly with imperfect information. Irreversible decisions deserve more deliberation precisely because the cost of being wrong cannot be reclaimed.3
  • Optionality. Does this choice preserve future flexibility, or does it lock us into a particular vendor, architecture, or business model?
  • Information value. Will making this decision teach us something useful, even if the immediate outcome is unsatisfying? Sometimes the cheapest way to resolve a disagreement is to ship a small version and look at the data.

A decision that is locally optimal but eliminates future options is often a poor economic trade.

Short-Term and Long-Term Costs Diverge

The cheapest short-term solution is frequently the most expensive long-term solution. This is the central economic tension in software work, and it shows up everywhere:

  • A custom in-house tool is cheaper than a SaaS subscription this quarter, and considerably more expensive across five years of maintenance.
  • Skipping tests ships the feature faster this week, and slows every subsequent change in that area for the life of the codebase.
  • Hard-coding a value avoids the work of building a configuration system today, and adds a recurring "where is that thing again?" tax to every future operator.
  • A clever abstraction saves a few lines of duplication today, and forces every future contributor to learn it before they can safely change anything nearby.4

None of these are wrong choices in isolation. The local trade-off may genuinely be the right call. They become problematic when the long-term cost is invisible to the people making the short-term decision.

What This Looks Like in Practice

A few habits follow from treating software as economics:

  • Make costs legible. Whenever possible, attach approximate costs to decisions: not just build time, but a sense of ongoing operational and maintenance load. "This will take a sprint to build and then about half a developer-day per month to keep running" is a much more useful framing than "this will take a sprint."5
  • Frame conversations in trade-offs. "Should we do X?" is a less useful question than "what are we giving up by doing X, and what would we be giving up by not doing it?"
  • Favor reversible decisions when uncertain. Where a choice can be undone cheaply, decide quickly and learn. Where it cannot, slow down. The cost of poor irreversible decisions is paid for years.
  • Treat sunk costs as sunk. Money already spent on a system is not a reason to keep investing in that system. The relevant question is always forward-looking: given what we know now, what is the best use of the next dollar?
  • Recognize that "doing nothing" is also a decision with costs. Deferring a choice is a position, not a neutral state. The cost of indecision is usually paid in opportunity cost and accumulating complexity.

Key principle

The cheapest short-term solution is often the most expensive long-term solution. Good engineering organizations make those long-term costs visible at the moment of decision, not five years later when they are paying for them.

See also: The Build Trap, Total Cost of Ownership, Estimates Are Forecasts, Perfection Is Irrational, Ethics of Spending Client Money, Technical Debt.

  1. Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975; anniversary edition 1995). The foundational text on why software economics resist intuitions imported from manufacturing and traditional engineering, and on the irreducible role of communication overhead in any non-trivial system. ↩

  2. Barry W. Boehm, Software Engineering Economics (Prentice Hall, 1981). The first major attempt to treat software cost estimation and trade-off analysis as a rigorous economic discipline, and the source of the COCOMO model. ↩

  3. Jeff Bezos, 2015 Letter to Shareholders (published 2016). Introduces the now widely-cited distinction between "Type 1" (irreversible, one-way door) and "Type 2" (reversible, two-way door) decisions, and argues that most organizations apply Type 1 deliberation to Type 2 problems. ↩

  4. Martin Fowler, Yagni ("You Aren't Gonna Need It"). On the cost of building flexibility for needs that never materialize: https://martinfowler.com/bliki/Yagni.html ↩

  5. Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (Celeritas Publishing, 2009). The canonical treatment of cost of delay, queueing theory, and the economics of batch size in product development. Reinertsen's argument is that most organizations fail to make economic trade-offs visible because they do not measure the right quantity (cost of delay) and therefore optimize for proxies (utilization, completion rate) that produce systematically wrong decisions. ↩