> The productive life of any particular blob of source code is an awfully complicated thing to talk about

The IRS does this all the time. Code isn’t some special magic enigma, businesses depreciate property, trucks, aircraft..all of these are equally as complex as code or significantly more complex to value over time. Usually it’s simplified to some degree for practicality, as I’m sure this will be.

I completely agree with that! One requirement of effective taxation is having this granular, high-resolution inspectability of economic activity, but also keeping it abstract and general enough that it can be more efficiently be used a large number of diverse businesses.

I understand :)

So you think software development costs should not be capitalized, right? What makes you say that?

I think it's more complicated than that. Some software is developed and then provides value to the company that owns it in a way that is clearly comparable to other capital investment. But lots of other software just isn't. There's also the problem of differentiating between ongoing work that is supposed to just be "maintenance" and essentially identical work that is "updates" and "new features". Even at the code level it is not always easy to tease these apart.

Also, the change to Sec 174 is related to R&D expenditures. This is also another aspect of trying to fit a multiheaded hydra into a small sphere: yes, some software development does share many similarities with R&D activities, but lots of software development does not (unless you label R&D in a way that is so broad as to encompass just about anything).

If the US wants to force amortization on software development expenses, I think that should be stated more explicitly, and with a much more detailed rationale. Just tacking it onto the "R&D" category really serves no-one very well at all.

> Just tacking it onto the "R&D" category really serves no-one very well at all.

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.

A lot of software has a Ship of Theseus character. The code base may be 5+ years old but all of the actual code is significantly younger and is completely turned over on a much more frequent basis. The practice of CI/CD, which is spreading across software domains that would have been unthinkable a decade ago, is only encouraging it.

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.

Ok, this is a very interesting and in-depth overview of the modern realities of software development.

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! :)

It's not so much that the software does serve as a long term asset, it's that it isn't a static long term asset - it only maintains its value by being maintained, updated, extended. The work that was done on it 5 years ago, or 10 years ago, laid the groundwork for the value it has today, but that value would be zero or close to it without continued work.

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.

This is very similar, it seems, to how software is modeled in the current IRS guidelines. The asset is not static, infinite-term one, but one that depreciates over time. The guidance points out that companies are expected to account for depreciation and can amortize their capital expenditure over 5 years. It's not a perfect model of every possible software org, but it seems in line with reality.

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.