[patmcc]

They're still expenses, they just now need to be amortized.

Buying a truck is an expense, as is buying gas for the truck. But the former you have to amortize over x years, the latter you can expense immediately.

The law used to be "employee salaries for software are like buying gas" and now it's "employee salaries for software are like buying a truck".

[jandrewrogers]

The critical difference is that the business owns the truck but not the employee. The amortization assumes that the asset can be sold for value. An employee can quit at any time for any reason. You don’t retain the right to their labor for five years.

[patmcc]

If they're producing a capital asset, you do retain the right to the fruits of their labor, even if they quit.

The rationale behind amortization isn't exactly the idea that the asset can be sold, it's that the asset is producing revenue over multiple years. For software, the asset is the codebase.

Let's say you hire a single software dev, for one year, and they write Excel++, which you can sell for the next ten years. It would be entirely appropriate to amortize the cost of creating that software over those ten years, based on the matching principle (a fundamental idea of accounting, matching expenses with revenue).

The issue in the real world is that's not how the software industry actually works, 99% of the time.

[demosito666]

> The issue in the real world is that's not how the software industry actually works, 99% of the time.

What would be a more appropriate model from accounting perspective?

[patmcc]

Honestly it'd depend a ton of the particular industry/company/programmer. Some are definitely creating capital assets and should be amortized, others are "repairs and maintenance" which can be expenses. I'd probably defer to treating them as expenses, but allow for amortization if the company desires, and maybe have some audit possibility on that if it looks like the big players are gaming that somehow.

Part of the complication here is companies generally really like amortizing stuff. It lets you smooth your profit across years which is usually better both for tax purposes and for your financial reporting for the market. So this kind of change is fine or even good for a company like Google, but can really suck for a small bootstrapped SAAS. This is why I'd allow companies to pick, with some degree of latitude.

[jandrewrogers]

As anyone that has ever sold software IP knows, most of the value is vested in the person that wrote the code, not the code itself. The code is not a factory, it is the output of the factory.

[simoncion]

> ...most of the value is vested in the person that wrote the code, not the code itself.

You must have misphrased what you intended to say. If what you wrote was true, a software company's most valuable asset would be the specific programmers in its employ. If true, average tenure of a programmer would be way longer than 1.5->2 years as companies worked really, really hard to keep their most valuable assets from walking out the door into the doors of another company just to get reasonable pay increases.

Perhaps your opinion is influenced by doing post-collapse-sales of a whole bunch of software houses that built just plain bad software? I can't see why else you'd be selling "software IP" independently of the rest of the business.

Anyway. Given that information, how should you have phrased what you wanted to say?

[jandrewrogers]

Most programmers do approximately zero work that is R&D. The most you lose if they walk out the door is institutional knowledge.

On the other hand, I've worked almost exclusively on software R&D for decades and seen the loss of a single person effectively end a project even when the software was essentially finished. Software R&D is about developing abstract knowledge, concrete implementation code is just a useful byproduct of that since R&D is typically motivated by a specific novel requirement.

If the software IP that results from R&D is not core to your business or a competitive risk, there is money to be made by licensing it. I've licensed this type of IP to big tech companies a number of times. If you are not actually doing software R&D, you are unlikely to be in a position where this is a possibility.

In almost every IP sale and licensing deal for software R&D I've seen, the value of any code is almost entirely conditional on retaining the services of person(s) that designed and wrote it. The entire "acquihire" phenomenon is an explicit admission of this. This is true even when the code is in a mostly finished form. Companies are buying capability, not revenue, so the code can't be a black box to their engineers. Companies usually spend more to acquire people with the code knowledge than the actual code.

The practical reality is that it is difficult to reverse engineer abstract knowledge from a concrete implementation. No one wants your code per se, they want to adapt your code to a different application that requires having a deep understanding of the domain the code represents -- they don't know what they don't know.

If you are just grinding out software that could be vibe coded then there is minimal asset value being created in the software artifacts. Anyone else would be better off reimplementing it themselves.

So yes, almost all of the value of code produced by software R&D vests in the people that wrote it. This is evident across many software IP transactions.

[simoncion]

> Most programmers do approximately zero work that is R&D.

So, what you're saying is one or more of the following:

1) The work of most programmers should not be considered R&D, and shouldn't be covered by tax schemes intended for R&D.

2) Most "software IP" in the industry is not the result of R&D.

3) You've rarely been involved in the sale of non-R&D "software IP". (Do recall that your original statement was "As anyone that has ever sold software IP knows, most of the value is vested in the person that wrote the code, not the code itself.")

[8note]

the company owns the IP that the employee made though.

if anything, the amortization should match copyrights or patent lengths