Total Cost of Owning a Feature

Software development is a type of investment. How much should we invest in building an idea, and how can we calculate the total const of ownership?

A colleague once told me, “We build it — we own it.” It meant that once our team develops a feature and releases it, we will have to maintain, fix and improve it as long as it is used in production. If we could summarize all the days spent on a feature during its entire lifecycle, from defining requirements, through development and fixing issues, until decommissioning, we would know the total cost of owning it. Will it pay off and how much? How difficult is it to guess the total cost? And why does it matter?

Total costs of owning a product or a feature matter because maintenance, bugfixes, and other operational expenses negatively affect the profit. We want to decrease these. Here is an example of why is it sometimes difficult to understand these total costs.

Let’s take a look at transportation as an example. Here is a list of a few activities that take a lot of time and effort without a car: going to work, taking children to school, picking up groceries from the supermarket, visiting friends on the other side of the city, transporting a piece of small furniture to your home, going to the countryside, and an urgent visit to the hospital. These are all benefits. But what about costs?

Costs-wise, first, you need to buy a car (and its value keeps dropping from the moment you drive it off the lot). Then, fuel costs money. Insurance too. Your time and money to take a car for maintenance are costs, as are your time and money to obtain a driver’s license (one-time costs but necessary). You will have to replace the tires and brakes from time to time. People who keep track of all these expenses know how much it costs to own a car, both in terms of the initial purchase price as well as ongoing expenses.

For some people, a car is a good investment that saves them time. On the other hand, some people don’t need a car at all. For example, a friend of mine lives in the center of Amsterdam and he doesn’t even have a driver’s license.

To make a good decision about whether to buy a car — and which one — we need to know the context in which it will be used. Software products are the same.

How much owning a piece of software actually costs

There are various expenses tied to every piece of software we produce, and these costs exist for the components’ entire life cycles, whether we account for them or not. They all show up directly or indirectly on the company's income statement (profit/loss).

• defining the product vision
• writing the requirements
• selling the product/service
• development
• configuration and maintenance
• infrastructure
• resolving the technical debt
• training users and developers
• cost of integration in the target business (often neglected)
• documentation
• handling outages
• etc.

Having a good and clear overview of all these helps us define a good MVP, prioritize, and make decisions. I learned more about the concept of TCO by studying the basics of managerial accounting and I applied it to software/product development because a sense of investment is at its core. I would recommend that any engineering professional study the basics of managerial accounting, because things like fixed/variable costs translate nicely to software development.

Cost of development and cost of operation

One way to observe the costs of a product is to split them into two categories:

1. cost until launch (development)
2. costs after launch (operation)

The team that launches the product may also be responsible for operations and uptime. In some companies, that is not the case; there may be a separate department that is responsible for uptime and operations. Both modes have advantages and disadvantages.

Profit

Typically, a product can start bringing in revenue after the launch date, and the more we optimize the costs, the higher the profit. For the sake of simplicity, let’s assume that all these variables are linear in time.

^{A (very) simplified “cost vs. benefit” diagram of a product in time.}

Modern development methodologies revolve around the idea of incremental development. This means we don’t launch products with all possible features at once but split them into many launches (one or few features at a time). This split makes the TCO calculation a bit more complex, but it is often enough to simplify one product as a sum of individual features (or clusters of features). We can use multivariate testing and analysis of how users interact with a product to optimize for profit by reducing costs, removing useless features and finding opportunities for improvements based on this testing and analysis.

By the way, when is the last time you heard about a team who removed a feature and how often does it happen?

An important benefit of incremental development is to make sure that the budget is optimized for profit and not spent on features that will bring no proven benefits. In modern software products, launching as soon as possible (MVP) and fast iteration is important because we are looking for confirmation that the benefits customers are looking for will appear — and if they do, we adapt the product from there to optimize for more profit (revenue vs. operational costs).

One possible pitfall is to forget to include metrics in the product itself. Doing this will provide data-driven insights about usage.

Since all features and products start with ideas (hypothesis), and people love their ideas, there are often many unwarranted and enthusiastic projections of “revenue” and benefits. However, without that enthusiasm and driving force, there is no movement forward. So there’s a constant struggle between ideation and optimization. It’s a normal and healthy thing, and if all sides understand the TCO, it’s easier to do the right thing.

Who benefits from knowing the TCO?

Everyone. If engineers understand the concept of investment and how budgets drain over time, they can focus on optimizing the development and maintenance efforts.

If business/product people understand the TCO and how much it really costs to develop and maintain a product, they can optimize the feature requirements and prioritize better.

A practical approach would be to have something like a template custom-tailored for your context (company, teams, industry) with a list of checkboxes that show the costs during the lifetime of a typical component. I don’t think it’s possible to compile such a list in one go (except for the most simple applications), so this should be a living document that you can expand and edit as you gather experience and customize per application. Team effort is also valuable in this case because it’s rare for one person to know all the elements of every cost. Products can affect multiple different types of users and require a multi-disciplinary team to develop.

Technical debt

A software product that runs in production makes and spends money at the same time. The goal is, of course, to make more money than it spends. The cost of technical debt is twofold: 1) engineering time wasted on maintenance, and 2) slowed down delivery. There is often little to be found about technical debt or maintenance and how that affects products’ profitability. I wrote a separate article about that.