101–110 of 211 posts
Earlier quoted context omitted.
Or you can continuously keep your code / systems up to date and never get wedged into a nearly impossible situation of having to rewrite 60 year old code (which likely has nothing resembling a test suite nor even a spare piece of compatible hardware to test on).
> Or you can continuously keep your code / systems up to date Easy to say as a grunt, but businesses (and governments) are run by managers and accountants. What you describe is upgrading for upgrading's sake. If a system isn't broken, there's no point or financial reason to replace it. Imagine trying to upgrade a system with incredibly complex data on a BILLION users that has to work 24/7, then deal with massive data…
I think you're over-estimating the amount of data involved. There were about 150M individual tax returns and ~5.8M corporate returns in 2015. Even if we assume 50 years of storage in the 'active' dataset that is > And not only take in and sort those records, but validate the data and perform calculations based on rules that change almost monthly, and that sometimes must be applied to years-old data and sometimes not.
I might believe that is an issue if the IRS actually calculated everyones taxes for them and sent out a 'do you agree' form, but they don't. It's more like they randomly sample some returns based on some hand picked 'warning' flags and have someone manually check them, maybe with the help of some excel formulae.
Earlier quoted context omitted.
The oldest parts are not System 360, they run IBM 7074 assembly. Just FYI. The caching system is much newer, they have some Java proxy, there were posts about it the last year.
I assume it runs under an emulator by now. Once I did manual disassembly of compiled code back into a high-level (for the time) language. It wasn't very fun, but , thankfully, the compilers of the day didn't optimize much. It'd be a fun project.
the compilers of the day didn't optimize much
I feel like the authors of this article are being very misleading by using broader terms where they could be more specific, like using system where they could instead say software. The IRS isn't running 60 year old hardware, and the failure was in hardware that was just 18 months old. But because the IRS is running software that is 60 years old, the authors can claim the "system" dates back to the 1960s. It's also cl…
Feel free to not read articles written by non-tech people. Or, acknowledge the fact that a journalism major can only put in words what he understands of a deeply technical matter that's outside his expertise
Earlier quoted context omitted.
It's general reporting by general reporters using general language for the general public. It's not a tech publication. Joe Lunchbucket doesn't care if it's hardware that failed or software. The system failed. That's what his tax dollars pay for.
There's no reason not to include the details. People who don't care can ignore them.
It is the job of the writer to write for the audience, not include every single detail, no?
I feel like the authors of this article are being very misleading by using broader terms where they could be more specific, like using system where they could instead say software. The IRS isn't running 60 year old hardware, and the failure was in hardware that was just 18 months old. But because the IRS is running software that is 60 years old, the authors can claim the "system" dates back to the 1960s. It's also cl…
It's general reporting by general reporters using general language for the general public. It's not a tech publication. Joe Lunchbucket doesn't care if it's hardware that failed or software. The system failed. That's what his tax dollars pay for.
Joe Lunchbucket doesn't care if it's hardware that failed or software
Earlier quoted context omitted.
> Or you can continuously keep your code / systems up to date Easy to say as a grunt, but businesses (and governments) are run by managers and accountants. What you describe is upgrading for upgrading's sake. If a system isn't broken, there's no point or financial reason to replace it. Imagine trying to upgrade a system with incredibly complex data on a BILLION users that has to work 24/7, then deal with massive data…
Imagine if you were an airline that didn't bother to maintain planes. When you build software you should plan to maintain it. Bug fixes, features, upgrades, etc...
Earlier quoted context omitted.
To be fair, 140 million taxpayers account for a lot of punchcards.
(assuming it is not /sarcasm) The data is not stored in punch cards, the programs are/were. The data is/was stored in tapes or in tape emulators. Storing data on cards would make random access wayyyy too slow (the operator would have to retrieve and load the card and keep them sorted manually, which is impossible to do at scale) On tape, however, you can predict the distance you have to rewind by computing the physic…
Earlier quoted context omitted.
Modern cars in general get much better mileage and are much safer to drive in. (Yes, airbag shrapnel has happened.)
Only if you're driving forwards. The crash test rating arms race gave us vehicles we can't see out of then we backed over so many kids that the federal government mandated a rear camera in everything.
Earlier quoted context omitted.
> Secondly, I'm not a big fan of how you (and quite a few economists) conflate personal and corporate income taxes. It really muddies the water as even questions like "what even is income" is different between the two. It was an example of how nominal tax rate is not the same as effective tax rate. For example, mortgage interest deductions are a regressive benefit which lowers the effective tax rate. Unfortunatenly,…
Once again, progressive vs regressive has nothing to do with how much you get back in services. That's literally not a component of the definition. You might be confused because deductions are a component of how regressive a tax is.