page updated on December 31, 2020

The Economics of Software Maintenance

Programmers have endless debates over whether their profession is art or engineering. A professional programmer's job title may contain the word "Engineer"—a division in the company may lump all of software development into the classification of "Engineering". Yet if you've been around programmers for any length of time, you've likely heard the word "elegant" used to describe otherwise ineffable qualities of software. These qualities adhere to aesthetic principles which relate more closely to taste and style than they do to functional requirements.

Software bridges an uncertain and misunderstood gap between the very practical needs of a business (to produce payroll reports, to control large machines in a factory, to model the plastic casing of a consumer device) and the more abstract requirements of the people responsible for designing, implementing, deploying, and maintaining the software (easy to change, simple to understand, able to be monitored). This gap isn't the schism between engineering and art; in many ways, the qualities which developers would like the software to exhibit represent tradeoffs present in many engineering disciplines, while the business requirements the software must meet have an unreality of their own.

Yet any software written to meet business goals must meet at least one fundamental standard: to provide sufficient value to justify the investment required to build, deploy, and maintain it. If a widget producer spends $100 million dollars to build a new widget factory but can only realize $50 million in revenue over the lifetime of that factory, the investment has failed. (The numbers are worse than they seem at first; presumably the initial investment was the net present value of a much larger sum. In other words, the widget company would have been better off investing in something which returned even 1% or 2% than investing something which lost money. This may seem like a very peculiar and pedantic point, but merely breaking even on an investment is often a failure from a business perspective.)

What is the Return on an Investment in Software?

A business can provide value with software in one of two ways: by increasing revenue (bringing in more money) or by improving productivity (reducing costs). These are the same two options as most other business operations, excluding finance (for an unrelated example, consider how a stock buyback may improve the financial position of investors in a public company). Many businesses consider software—IT in general—as a cost center, in that money flows in and, ideally, productivity improves throughout the company. Though the new Silicon Valley ideal of companies which provide services based solely on software (cloud hosting, online payment collection, video conferencing) have a different view of the economics of software, many or most companies do not see software as enhancing revenue.

If this is the case, how does a company measure the effectiveness of its investment in software intended to improve productivity?

In practice, poorly.

Imagine a law firm without email, multi-line telephones, or even computers with word processors. (It still has a fax machine and a copier and a water cooler.) To some extent, the idea that every attorney, paralegal, and legal assistant should have a computer on her desk and Internet access is just the cost of doing business, as is the idea that every attorney should have a desk. (Who measures the effectiveness of a partner at that firm who's never learned to type and who writes all of his documents longhand, expecting a legal assistant who bills at $70 an hour to transcribe his scribblings? Certainly not the poor client who doesn't see that inefficiency on the bill!)

An expensive legal library service such as Lexis-Nexis or Westlaw will make the argument that spending thousands of dollars per year per seat will save workers hours of effort poring through the library of dusty law books slowly growing out of date in that hallway just outside the cafeteria. They can even put a dollar amount on that value. Do you trust that figure? You could measure the cost of research with and without, and figure out how you can keep clients happier or bill more with and without that service. You will have trouble measuring how much more effective your work is with the breadth of access to a digital library and a larger index, however. Would you have made a successful pleading if you hadn't found that interesting legal theory that just happened to show up in a search? Would you have even stumbled across the relevant precedent while browsing the shelves in person?

(The business value of subscribing to such a service is wildly different if you are in-house counsel. Productivity to a single client which pays you a salary is very different from productivity to multiple clients, all of whom you bill directly.)

Of course, the decision to license software is very different from the decision to build software. One reason Lexis-Nexis and Westlaw charge so much is that they have the responsibility of keeping their software working year after year. Unlike a printed book, they cannot produce a single edition which will last until the spine falls off and the print fades. The ephemeral qualities of software and the steady march of technical progress mean that software requires a continual investment in upkeep to remain useful. If you want the software to do more (to bring in more revenue, to improve productivity further), you must consequently invest more resources in the software.

If you invest nothing in the software, it will fall further behind in usefulness. This is one blind spot which companies often exhibit when they consider software.

If you were to build a mathematical model of the utility of software and its return, you might start with the idea that the decision whether to invest in building software should look something like this:

$investment <= Net Present Value of $expected_return

In other words, if you believe it'll cost $1 million to produce a piece of software and you expect it to produce $1.1 million in new revenue or productivity improvements in one year, and if a 10% return is acceptable, then you're doing fine.

(Yes, the financial calculation is different whether the value the software produces is top line or bottom line, but if you already know that, you also know how to do the math differently and that doesn't change the point.)

Set aside the fact that it's very difficult to estimate the cost of building software before you've built it (designing software is exceedingly difficult due to its inherent complexity, measuring progress in software is difficult due to its ephemerality, and the unknowns tend to multiply in areas where intangibles grow). These are projections. You might spend less. You might gain more. You have to run these numbers as your best-understood estimates. At a minimum, this equation will help you measure the result of investing in software. (Run it backwards to figure out what you should have paid for the value you did realize.)

What if you want to model the maintenance costs of software? Is it worth it to invest in keeping it running? The formula looks much the same, except this time it includes the expected yearly maintenance costs:

$initial_investment + Discounted Value of $maintenance_costs
<=
Net Present Value of $expected_return

Discounting the expected maintenance costs over the lifetime of the project helps to account for the ways in which you could put that money to better use later. (A dollar now is worth more than a dollar in the future. Of course, you may not pay those maintenance costs now, but if you're deciding whether to invest in that software now, you're taking on those maintenance costs in the same way that taking out a loan means you're taking on debt service costs for the life of the loan.)

This latter calculation is much less reliable than the former, for the simple fact that its variables represent more unknown qualities. How do you measure the maintenance costs of a piece of software?

Sources of Maintenance Costs of Software

Maintaining software depends on multiple factors. This list is not exhaustive, and not all factors apply in all situations:

• cost of maintaining a hardware platform on which to run it
• licensing costs for hardware and software dependencies
• cost of IT workers to monitor hardware and software
• training costs for new users
• porting costs to new platforms
• cost of fixing bugs
• cost of adding new features
• cost of interoperability with existing or new systems
• training costs for new maintainers

Outside of some specialized situations (for example, a monopoly, monopsony, or cartel position where vendors can charge exorbitant licensing or support fees), the largest single cost for maintaining software is personnel. Hence the final item in the list: if you've built software on which your business relies, you'll find yourself paying for the expertise of people who can maintain it. If you don't retain them, you'll pay costs both direct and indirect to hire and retain people who need to learn the details of that software.

Measuring these costs is difficult. Then again, so is measuring the costs of lost productivity and especially of missed opportunities.

Managing Software Maintenance Costs

If managing software sounds daunting, that's because it is. Software's essential nature presents a complexity that can only be controlled, never entirely contained. Any modern software project running on general purpose computers (a server, a laptop, a tablet, even a phone) relies on the interactions of tens or hundreds of millions of lines of code, multiple levels of hardware, and countless vendors and developers. These components change yearly.

The nature of business is no less chaotic, especially due to the presence of the single largest source of chaos in either endeavor: people. The action or inaction of a single employee may cost a company billions, while the action or inaction of a software developer may introduce a bug or implement a feature which can make new ideas possible or cause countless errors.

Treating software as a cost center may, unfortunately, exacerbate the negative.

Perhaps the primary difficulty in understanding the cost of software is its complexity. Which of the tens of millions of lines of code have the greatest effect on your business? If you had only a few thousand dollars to invest in making a single change, where would you see the greatest results? Even if you had the ability to focus your efforts in a single place across the whole stack, there are too many choices to evaluate. You'd spend an enormous amount of time, effort, and money considering all of your options.

Perhaps the problem is too large. Perhaps the costs and expected values are easier to evaluate in smaller quantities.

For example, what if you have a room full of workers who spend an hour each day transcribing data from spreadsheets into a web application. If each worker costs you $14 an hour and you have ten workers, that's $140 a day, $700 a week, and $35,000 a year.

Suppose it takes a developer who costs you $700 a day one week—$3500—to implement a feature to upload spreadsheets and import that data directly. In five weeks, you'll have recouped your investment by improving the productivity of ten workers.

This approach does have its limitations. Not all features are that easy to quantify, nor are they that dramatic. Yet the nice thing about software features is that they tend to amplify each other. Every exploited opportunity for automation has the potential to expose further opportunities. (Your workers not only are free to work on other things but they'll experience less tedium and, consequently, you may have improved retention.)

It's unreasonable to expect that you can measure the direct economic benefits of each line of code written, but it is possible to analyze the expected and realized benefits of each feature implemented at a certain granularity. Perhaps the correct granularity is at the level of a developer's work week. Perhaps it's a day. (The amount of detail required relates directly to the amount of direct supervision over the development process. Given accurate measurements at the weekly level, it's possible to summarize costs, expected benefits, and realized benefits at aggregate levels.)

This model does, of course, require a baseline set of costs of keeping the software running at all (hardware, licensing, available emergency support personnel) as well as the expected recurring benefits (if the software stopped working, what would be the costs to productivity or revenue?). Yet with those costs in mind, it's possible to analyze the expected remaining value of the software against costs of replacement or deprecation.

Few companies manage this well.

Software is poorly understood at all levels, especially cost and benefit. That doesn't have to be true. Even an economic model as simple as the one provided here can offer insight into what you're paying for and what you're receiving. Even the exercise of asking questions about cost and benefit at the granularity of a developer week may reveal information you previously lacked—information which can help you make better decisions about how you manage, and pay for, technology.