A major source of short-term-ism in software value is the blurring or outright erasure of the boundary between development and operations, and the reality that more software is architected under these assumptions. Unlike features, operations is a constantly moving target, and it can reach pretty deeply into your software stack.
Anecdotally, for the types of software I work on, probably half of the development work exists to satisfy an operations rather than product feature need. These are often chasing exogenous metrics like improving opex. A lot of this work becomes irrelevant or dead code in much less than five years as the sands shift or we need to do things differently.
I am old enough to remember when software components almost always reached a state of “done”. That is rarely the case anymore. Testing has massively improved since then so the threshold above which companies will replace working code has been greatly reduced since the risk of doing so is much lower. We do forklift upgrades now that would have been unthinkable 20 years ago because of how thorough modern testing and tooling is.
One thing that strikes me is how this is similar to how a factory operates. While the existing tooling certainly is used for mass production, it is also regularly retooled for new requirements. These might be small changes, involving only a few minor molds or stages, or very large ones, involving complete replacement of whole sections. These operations also face the shifting sands of obsolescence and modernization, as well as changing market requirements.
It seems reasonable that all the expenditure to create the current tooling of the manufacturing plant is a capital expenditure, even tho, like software, it is never "Done", but rather in a constant state of progress and development. All of these iterative changes are likewise much akin to a form of research, albeit incredibly practical and occuring right where the rubber meets the road.
The modern picture of software development and operations you very clearly layout makes this capex framing more imperative and reasonable than before, despite not producing "done" assets. While it's certainly true that installation costs, bug fixing, and testing during production are not easily seen as capital expenses, it sounds reasonable that the other work to produce these production assets really is capex.
It also seems as if the IRS guidance already specifies this distinction, with the former category being specifically excluded from the proposed rule changes. Thank you for this very engaging and informative discussion! :)
That happens for a variety of reasons, including but not limited to: changing platform requirements, deeper understanding of user requirements, changes in user requirements, new external interaction possibilities.
As a small example from my own little world of digital audio workstations: ardour version 2 (from around 2002) was pretty good at doing all the things it did back then. But in 2023, that list of features in a DAW barely gets in the door for consideration as a tool for most potential or actual DAW users. That codebase (the v2.0 one) in and of itself is of close to zero value at this point [0], the only reason the project as a whole continues to have value is that it gets updated and extended to meet the expectations (to whatever extent it can) of users in 2023.
So, is the work I and others did in 2001 (pre v2.0) sensibly treated as a capital expenditure, or was it just "work" ? Further, when an architect designs one house for a client, then another for another client, then another for another client, why is that not treated in the same way? Each house is essentially and R&D project from which the architect carries forward a bunch of acquired knowledge and skills. I think the answer is reasonably obvious: we regard the project as each individual house, not the capabilities of the architect (which hopefully grow over time). With software, it's not clear quite why v2.0 and v3.0 and v4.0 etc. are considered to be "merely" updates rather than distinct projects similar to an architectural project.
Another point I would make about R&D: one of the justifications (I suspect) for having a deducation for such expenditure is that you don't really know if it is going to work out in terms of resulting in a new, or improved, item or service; because we officially want to encourage "innovation" we want to provide a bit of incentive to do the spend anyway ("you can claim it as a deduction").
I just don't see this as true with software work, particularly not software work on existing projects. Uncertainty levels are low - the chances are overwhelming that an attempt to add feature X to an existing project will be successful. And there are, as I described above, more than adequate motivations to do the work - no tax deduction is going to drive adding new features to an existing project in any sane world.
Again, I do acknowledge that there are software development and distribution models that are closer "work, work, work, work for N years, sit back and sell the result for M years, with a bit of maintenance work on the side". It seems much more appropriate to treat that as capitalization. The IRS allows people/companies to make a choice between cash-based expensing and amortized expensing of many costs - I'd prefer it if they acknowledged the difference for this purpose too, and allowed software development to be "cash basis" or "capital". Obviously, a set of returns that shows years of revenue with very little expense and that claimed "cash basis" would be seen as fraudulent.
I'd also note that the lawyer who posted a link to his Bloomberg article on this matter did not concur that the IRS has "quite clearly" defined maintenance vs. upgrades.
[0] and of course, as pointed out by a sibling comment, not very much remains of that codebase either, further underscoring the non-capital-like nature of software, at least over much shorter time frames than, say, a building or a piece of manufacturing equipment.
Thanks for your comprehensive comment! There's a lot for me to digest there, please allow me some time to read and comprehend it all! I may comment more later.
Well, it is called Research and Development. Perhaps that is the right place for it? :)
But your point about it being tacked on is well taken. However, I don’t think this problem is unique to this instance. It’s similar to updating software. When you update the law, you often have to tack things on and find a way to make it fit.
To their credit, the IRS has taken pains to define what constitutes software, as well as to differentiate between what is merely maintenance—including bug fixes and so on—and what constitutes upgrades and enhancements. They’ve specified this quite clearly in the guidance, which perhaps addresses your concern about distinguishing these different activities.
You acknowledge that there is certainly software that companies create and then use or license to others, providing them with long-term value, much like an asset. However, you also suggest there’s a lot of software that doesn’t serve as a long-term asset.
I’d be interested in examples of the type of software that doesn’t provide that long-term value.