Yes, if your company has builders that build you an asset (like a warehouse or a factory or office building) then you always had to amortise those salaries together with all the other expenses for building that capital asset.
That's not the case if you contract your builders out to build a house for someone else and they pay you for the hours, but IMHO it's also not the case (even with the new changes) for software developers being 'rented' as contractors to build stuff for others and the company getting paid for their hours.
I think the theory is that you can't keep selling the same house each year so you've just developed inventory and not long term assets.
Though, the country where I work and live, R&D has more profitable tax treatment, your employee costs are a same year expense, but you can get some relief on the rest if your tax bill if you proactively document what's R&D about your work and it doesn't get rejected by the tax department
Do your builder developers build the same thing over and over again like builders who build identical houses over?
I get the point but software really is different. Rarely ever are you building the same thing over, both from a “structural” or “architectural” perspective and from a functional perspective.
If your builders are creating a brand new blueprint for every house /structure and designing everything from scratch then I think it’s more similar, probably closer to commercial property builders with large structures.
Now under that perspective, I still don’t exactly understand why you’d treat labor cost deductions differently. Maybe the fact that these more complex products and services being built have higher return potential? I don’t know, I’m searching for a rational reason.
But, I do disagree treating software like something as commodified as many forms of labor. Someday we may get to that point with simple principles and procedures to follow, albeit technically, but we’re not there yet. At higher levels that may not be much “research” that’s needed but where the rubber meets the road, your engineers are checking to see what exists and doesn’t, designing new solutions to fill gaps in between, testing things, digging into previous things that don’t work and trying to fix them… it’s research.
As we continue to move more professions to an intellectual economy, many roles are becoming more and more like this, not just software. I’d say loading more roles and expectations on labor is also creating this situation where we’re asking more people to do more things they don’t know or can’t possibly know everything at a proficient level and the things we’re asking them to do don’t have solutions that can be written down and quickly referenced when needed as a simple recipe to follow. If you make the recipe general enough (e.g if a problem arises, find a solution and fix it at a low cost) then one might point to such highly generalized solutions and pretend it’s a solved problem but it’s not, it lacks any useful concretization. “You're not doing research, I told you ‘if a problem arises fix it’! There’s nothing to research you just do that!” doesn’t cut the muster.
That's not the case if you contract your builders out to build a house for someone else and they pay you for the hours, but IMHO it's also not the case (even with the new changes) for software developers being 'rented' as contractors to build stuff for others and the company getting paid for their hours.