Comment by joebob42
2 years ago
Very few pieces of software in my experience are doing anything 5 years later. 5 years seems like an extremely long time to be amortizing over.
2 years ago
Very few pieces of software in my experience are doing anything 5 years later. 5 years seems like an extremely long time to be amortizing over.
Removing the financial aspect for a moment, since I'm not informed enough to comment, I would like to say lots of companies are essentially running on software way older than five years and a lot of their employees don't even realize it because the 'new' development has mostly been repurposing the old software into apis and services that they then consume for their new stuff, but that old thing is still down at the bottom running the stuff, and the team doesn't understand it enough to do more than consume it, and there's always an ugly moment when something goes wrong and someone on an incident call asks "I thought that was retired?"
And then the devs do the "Well uh, it is, but we still uh, consume...uh...apis...endpoints... umm yeah it's not retired. Hank the ancient that now does dev finance built what we're using, we should get his help" And then hank gets on the phone with a sigh and fixes it.
I initially thought this was something exclusive to where I've worked, but after some years it seems to be true more frequently than I'm comfortable. When it's really bad you realize the entire company was built by Hank and maybe one other dude who got laid off and everybody else has just been making bootstrap wrappers of their tool for 15 years between the bare minimum to keep the servers compliant.
When I meet a software engineer that gives me the impression they're an engineer and not their clan's webmaster, it's kind of a cool day.
But this is also kind of making the opposite point: Hank wrote that thing 15 years ago, it wasn't even a large proportion of your long-term development expenses, and now all the other developers are actually doing maintenance work to keep the old code compliant with regulatory changes or integrated with external moving targets, none of which has long-term value because there will soon be other regulatory changes and the moving targets will move again.
Every DAW except Bitwig, every non-browser based image editing tool, almost every web browser, every OS, half(?) the apps in any app store, every IDE I can think of, every text editor and word processor and spreadsheet ...
all far, far older than 5 years.
But how much of the development effort for those took place in the last 5 years, even if the codebase is much older?
I’m not clear what you’re expecting.
Most of the development effort for such things happened in the past 5 years? That sounds unlikely.
Survivorship bias?
If/when software goes out of use, it can be written down and deducted immediately. The 5 years is a maximum, not a minimum.
I don't think that is true. From what I'm reading there is no acceleration.
What happens when changing broken parts on a machine that's amortizing, or repairs
Repairs and maintenance would generally be expensed.
Expansions and improvements would generally be capitalized.
I guess you could say this new tax treatment incentivizes writing more stable, longer-lasting software artifacts?
No, you don't get any extra benefit from the software lasting. The tax treatment is the same if it lasts 1 day or 10 years.
The incentive is to write software that is immediately profitable, and investing in long term projects becomes more costly.
The benefit you get from code that is useful for along time is that it’s useful, for a long time.
True; though for a counterexample, may I introduce you to TeX? Over 4 decades, and still in wide use.
Sure, there's been maintenance over the years, one significant version update (TeX 3.0 in 1990) and an ever-evolving ecosystem around it, but the core engine has been incredibly stable.
Why?
I think the obvious implication is that software development is expensive, ongoing and tends to result in relatively short term ROI, and therefore the amortization schedule of 5 years increases the likelihood smaller business will never collect most of it, while larger business that can absorb more up-front costs will be able to collect it pretty easily.
That is not an argument for tax treatment of whether something is an asset
4 replies →
Because most software devs don’t stick around long enough to write software that can stand the test of time. It requires a few things: like don’t use libraries unless they are well funded (includes frameworks) or have already stood the test of time (like bootstrap for the FE or React, etc); don’t hide logic deep in the code, put logic as high level as possible (like in controllers, which is the exact opposite of short-lived software; and many other little things.
I have several projects running in prod, at several companies, for over a decade. They are easy to maintain, easy to extend and build on, and easy to understand.
You can be changing the code every day and it’s still the same asset yhough
Because the world changes.