Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

nextgov.com

Post reply on HN
Print view View original

191–200 of 211 posts

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#191

Post by rbanffy »

DrScump wrote: post #103
rbanffy wrote: post #96

Earlier quoted context omitted.

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 worked in the IBM mainframe segment to start my career, and we actually had an awesome Capex optimizing COBOL compiler. We also had a core dump formatting system (not sure if it was part of the Capex set) that made dumps much easier to read and debug, plus they broke out the generated assembler code to make it quite intuitive. I got so good with reading their dumps that…

In this case, it was a C compiler for MS-DOS.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#192

Post by rbanffy »

DrScump wrote: post #136
heartbreak wrote: post #130

Earlier quoted context omitted.

Right because that's what we say about the Linux kernel too, right? If IRS is the maintainer, they still review changes. And so do all of us. If someone slips in an exploit, we'll catch it the same way every other open source project does.

Unless it's an exploit -able weakness that is discovered only because the source is open to be both read and tested against, like Heartbleed.

I sincerely hope that machine is not accessible from the open internet.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#193

Post by raverbashing »

romaniv wrote: post #137
raverbashing wrote: post #34

The question for the industry remains: how do we deal with systems that should be up for 10 years? 25 yrs? 50 yrs? 100 yrs? We didn't even have computers as they exist today 50 years ago. How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software?

>The question for the industry remains: how do we deal with systems that should be up for 10 years? 25 yrs? 50 yrs? 100 yrs? We didn't even have computers as they exist today 50 years ago. Is this a question the industry actually cares about? If anything, I'd say it got much worse at creating long-living software. It sucks to run a mainframe-based system from 50 years ago, but running a 10-year-old Web Forms applicat…

I agree it's a tough cookie. I actually don't think layers and layers of abstraction is a good idea.

But something were you can describe something like "Read this value from this field, do some math based on fields in another table, return the result"

That's why I raised the question, how do we do that over long periods of time without rewriting it in several different ways? (ASM to flat files, COBOL and JAVA to different SQL flavours, what else is next?)

And if you migrate, let's say from Oracle to MSSQL it will work for 90% of the things, for the last 10% it will be a PITA.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#194

Post by dx034 »

romaniv wrote: post #137
raverbashing wrote: post #34

The question for the industry remains: how do we deal with systems that should be up for 10 years? 25 yrs? 50 yrs? 100 yrs? We didn't even have computers as they exist today 50 years ago. How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software?

>The question for the industry remains: how do we deal with systems that should be up for 10 years? 25 yrs? 50 yrs? 100 yrs? We didn't even have computers as they exist today 50 years ago. Is this a question the industry actually cares about? If anything, I'd say it got much worse at creating long-living software. It sucks to run a mainframe-based system from 50 years ago, but running a 10-year-old Web Forms applicat…

> Is this a question the industry actually cares about? If anything, I'd say it got much worse at creating long-living software. It sucks to run a mainframe-based system from 50 years ago, but running a 10-year-old Web Forms application can be borderline impossible. I'm scared to think of what will happen with all the cloud-based stuff in the next 10 years.

Cloud deployments, especially modular systems (and of course microservices) are often sold to companies as the best way to reduce technical debt. I don't think they've been around for long enough to truly test it but would be curious if a 30yr old system of microservices running in containers is easier to update than COBOL software running on a mainframe.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#195

Post by dx034 »

colechristensen wrote: post #176
raverbashing wrote: post #34

The question for the industry remains: how do we deal with systems that should be up for 10 years? 25 yrs? 50 yrs? 100 yrs? We didn't even have computers as they exist today 50 years ago. How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software?

>How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software? Come up with programming languages with limited domain specific functionality that don't allow you to do funny machine specific things. (or even ordinary things like pointers) Use the restricted languages for business logic and have a second language to do the plumbing. Or just target a…

So all critical software in Python or JS? Not so sure about that. I get the idea but think having strict code guidelines might be more effective than choosing a more restrictive language.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#196

Post by dx034 »

samlents wrote: post #156
justinator wrote: post #150

Earlier quoted context omitted.

Oh yes, 1000x maintainable with 1000x more lines in the codebase. Speak softly into my ear, these little lies you like to tell me.

Having not worked on large scale systems like what I imagine they must be working with, is this really true? I would have thought that a modern framework would make things easier. I've certainly had life made easier by modern web frameworks like React and Angular, although the support timeline is more on the order of 2-3 years, rather than 20-30.

Not sure, what if you have an enterprise system that uses a few hundred docker containers and at some point in 10-20 years there's a major vulnerability that can only be fixed by breaking compatibility for one function? Securing that system could be significantly harder than fixing a monolithic system.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#197

Post by dx034 »

georgeecollins wrote: post #144
jkaplowitz wrote: post #121

Earlier quoted context omitted.

Unfortunately that's true for most journalism. It's just that we techies are not usually subject-matter experts in the many other areas where they make mistakes. Consistently high-quality in-depth reporting is the exception and is not a threshold most media will accept as a publication bottleneck.

My Dad used to say: "The Economist "(magazine)"sounds authoritative until you read an article about something you are an expert in."

I still find they generally do a good job breaking down topics in a way most people can understand it. Often, being accurate also means being unnecessarily complex. If your goal is to explain research in an easy way, simplifying it will often introduce inaccuracy. That doesn't mean the writer isn't aware of it, they just try to get as many people as possible to read to the end (as this gets tracked online).

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#198

Post by dx034 »

mankash666 wrote: post #162
ep103 wrote: post #104

Earlier quoted context omitted.

Or, suggest that this is a low quality article, and if journalistic enterprises want to report on subject matter, they should have their articles approved by people knowledgeable in that subject matter.

You're assuming the target audience to only comprise of subject matter experts. This article is perfectly ok for 90% of the tax paying population that works outside tech

And maybe even better for those 90%. Introducing more technical terms (e.g. specifying the Assembler used) makes it less readable for anyone without the domain knowledge. Often, when trying to explain something to the broad public, making it inaccurate is a necessity.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#199

Post by dx034 »

sehugg wrote: post #164

A delivery date for CADE 2, the IRS’ subsequent modernization effort, has slipped several years even as contractors working on the project have earned as much as $290 million. They call them "Beltway Bandits" for a reason.

I'm always amazed that so many are outraged by Investment Bankers and Lawyers making millions when IT consultants get so little attention. Maybe it's because few people understand what IT consultants actually do and have no alternatives but hiring them but cost overruns due to increased IT consultancy appear much more prevalent than escalating legal costs.

Re: IRS’ 60-Year-Old IT System Failed on Tax Day Due to New Hardware

#200

Post by dx034 »

favorited wrote: post #2

Fun (scary) fact – significant portions of the IRS tax system is still written in assembly. It's basically the original codebase plus 40 years of additions and patches as the tax code changed. They were working on projects to "elevate" it to Java, because it's pretty difficult to maintain it as-is.

Most big banks run on COBOL, new Fintechs run on micro-services powered by Go, JS or whatever's trendy at the moment. I trust software with a proven track record of several decades with no considerable downtime more than architecture that's currently considered to be "best practice".

NB: Don't object any of the new languages, I've never written code in COBOL or for a mainframe. But I've also never developed software with that kind of requirements.

Post reply on HN