4 ms·

I agree that you could argue all these points. I have to agree, because I don't agree with any of them :) While the actual duration of software value is neith

I agree that you could argue all these points. I have to agree, because I don't agree with any of them :) While the actual duration of software value is neither the day it was created nor "forever", the idea that a fixed amortization schedule is appropriate seems clearly wrong to me. Even crazier that it would depend on the geographic location of the person who did the work. The productive life of any particular blob of source code is an awfully complicated thing to talk about, and the idea that the tax code should attempt to incorporate such a concept into a relatively simplistic rule (or pair of rules) seems faintly ludicrous to me.

keepamovin 3y ago
I understand :) So you think software development costs should not be capitalized, right? What makes you say that?
- PaulDavisThe1st 3y ago
  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.
  - keepamovin 3y ago
    > 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.
    - jandrewrogers 3y ago
      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.
oceanplexian 3y ago
> 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.
- keepamovin 3y ago
  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.

keepamovin 3y ago

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

PaulDavisThe1st 3y ago
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.
- keepamovin 3y ago
  > 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.
  - jandrewrogers 3y ago
    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.

oceanplexian 3y ago

> 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.

keepamovin 3y ago
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.