4 ms·

>nor should the bug fixer. Is a maintenance contract on a capital asset not capex?

patmcc 4y ago
It depends. If you have a truck - capital asset - the oil changes are probably opex, but replacing the transmission is probably capex. Regular sweeping and cleaning of a building is likely opex, upgrading the wiring capex. Software I can certainly see getting tricky here - is updating dependancies an oil change or a transmission? "Betterment, restoration or adaptation" is the usual test for something being capex.
- thfuran 4y ago
  Fixing bugs sounds like betterment to me.
phoehne 4y ago
My guess is a reported bug is opex, since it's fixing a defect on something that exists. But adding an API would be capex.
alkonaut 4y ago
Hot take: not one person on earth could make a good/useful distinction between "bug" and "feature" in software development. Some times that's clear, usually it's not. Making tax law depend on the idea that there is a distinction is pretty terrible.
- thfuran 4y ago
  In a world where all software actually has a comprehensive spec, I think the distinction could be made pretty easily, but the line is definitely fuzzy in this one.
  - alkonaut 4y ago
    Yeah I don't think that has happened even in (say) the most extreme niches like some project with an embedded 8 bit microcontroller in a space/military setting....
- patmcc 4y ago
  The current US tax law is flipping (with no rollout period) between dev salaries being 100% expensed (over 1 year) and 100% amortized (over 5 or 15 years). You actually could make some distinction between those two poles without being able to perfectly categorize every line of code. A number of things the government could do: 1) Split it between the two. Need to amortize x% but can expense the rest. Maybe that % is mandated, maybe it depends on industry (i.e. if you make games vs an OS vs a SAAS vs embedded software for cars). 2) Tie it to company size, either headcount or revenue. 3) Allow different categorizations for e.g. R&D, product support, building internal tools, building SAAS for sale, whatever. 4) Roll out any changes gradually over x years. Tax law, over and over again, uses the idea that there's a distinction between CapEx and OpEx. It's not magically impossible to do the same for software.

It depends. If you have a truck - capital asset - the oil changes are probably opex, but replacing the transmission is probably capex. Regular sweeping and cleaning of a building is likely opex, upgrading the wiring capex. Software I can certainly see getting tricky here - is updating dependancies an oil change or a transmission? "Betterment, restoration or adaptation" is the usual test for something being capex.

thfuran 4y ago
Fixing bugs sounds like betterment to me.

phoehne 4y ago

My guess is a reported bug is opex, since it's fixing a defect on something that exists. But adding an API would be capex.

alkonaut 4y ago

Hot take: not one person on earth could make a good/useful distinction between "bug" and "feature" in software development. Some times that's clear, usually it's not. Making tax law depend on the idea that there is a distinction is pretty terrible.

thfuran 4y ago
In a world where all software actually has a comprehensive spec, I think the distinction could be made pretty easily, but the line is definitely fuzzy in this one.
- alkonaut 4y ago
  Yeah I don't think that has happened even in (say) the most extreme niches like some project with an embedded 8 bit microcontroller in a space/military setting....
patmcc 4y ago
The current US tax law is flipping (with no rollout period) between dev salaries being 100% expensed (over 1 year) and 100% amortized (over 5 or 15 years). You actually could make some distinction between those two poles without being able to perfectly categorize every line of code. A number of things the government could do: 1) Split it between the two. Need to amortize x% but can expense the rest. Maybe that % is mandated, maybe it depends on industry (i.e. if you make games vs an OS vs a SAAS vs embedded software for cars). 2) Tie it to company size, either headcount or revenue. 3) Allow different categorizations for e.g. R&D, product support, building internal tools, building SAAS for sale, whatever. 4) Roll out any changes gradually over x years. Tax law, over and over again, uses the idea that there's a distinction between CapEx and OpEx. It's not magically impossible to do the same for software.