top | item 23535937

IRS programming mystery continues

141 points| lxm | 5 years ago |federalnewsnetwork.com | reply

77 comments

order
[+] jimrandomh|5 years ago|reply
Not a mystery, and discussed previously on HN before. The IRS abandoned this technology because it lost key employees, because it was not legally allowed to pay market rates for them. Discussion in 2018: https://news.ycombinator.com/item?id=16377804 .
[+] sokoloff|5 years ago|reply
I suspect this is at least half the problem. Imagine the team of software leaders you’d put together to pull off that project. Imagine the team of software engineers you’d need to implement it. These senior positions are paying mid-high six-figures in industry and the mid-level positions are paying $250K or more.

If the IRS is paying under $200K, making you follow government employment rules, work on an antiquated public works project, and giving you a terrible career development experience, it shouldn’t be any surprise the recruiting problem they face.

You can’t get the talent you need for this project because the talent you need knows that 500 is bigger than 200.

[+] tomohawk|5 years ago|reply
What usually happens in this circumstance is that the team forms a company and the government contracts with them for the work. Or, a large prime contractor reassembles the team upon getting a contract.

The fact that this did not occur points to a lack of capability on the part of the IRS to manage contracts.

The federal civil service really doesn't offer any sort of career path for technologists.

[+] aejnsn|5 years ago|reply
Can someone explain to me why the IRS even bothered with a patent application on software? Those are taxpayer dollars being used to fund that innovation--unless it's a classified technology, it should be public domain.

Furthermore, why did the IRS spend time and salaries to reinvent the wheel for a solution that is likely to exist as an OTS product?

[+] andrewstuart2|5 years ago|reply
Which part of the $3.5 trillion dollar-a-year processing system that interacts with 3.5 million businesses, tens or hundreds of thousands of HR systems, paper forms, tax laws, jurisdictions, edge cases, bank transfers, etc, did you expect to come Off the Shelf.

I work for a large bank, and yes, we use OTS software here and there, but that's such a miniscule part of the overall solution (let's completely forget organizational politics out of it). Try a few solutions, pick one, and get down to business because that was maybe 5% of the work.

"Just pick a business rules engine" is easy to say, but the meat of this problem is still the rules: thousand to hundreds of thousands of individual tax codes, jurisdictions. That, and the countless inputs and outputs the IRS presumably already deals with.

Couple that with the fact that politically, where do you think your career is going if you move fast and break things, and mess up $3 trillion dollars of revenue across 143.3 million tax payers, including some of your boss' biggest campaign donors?

Not to say it couldn't be done faster, easier, if you could break through the legacy and politics, but that's a really big if, and it still leaves you with all the complexity of the tax codes to implement on whatever great stack you find.

[+] aejnsn|5 years ago|reply
Shamelessly tagging off my own comment for another thought. Remember the articles about states' unemployment insurance systems at the height of the COVID19-inflicted unemployment in March?

They kept talking about hiring COBOL developers to address the current need. This next comment is intentionally vague--some federal government agencies offer frameworks for state governments to use in their own regulatory agencies. It's a shame we heard so little talk of that model in relation to state unemployment insurance systems at such an opportune moment. It's an unemployment insurance system--I cannot imagine there's too much creativity involved other than the clean integration of a business rules engine.

[+] thrill|5 years ago|reply
Patents can be used to protect yourself from others.
[+] Stratoscope|5 years ago|reply
I am really confused about something in this article and I hope someone can bring me up to date.

The article revolves around this patent:

https://federalnewsnetwork.com/wp-content/uploads/2020/01/IR...

The patent is assigned to "Internal Revenue Service United States Department of the Treasury".

The article also mentions that "two other related patent applications remain dormant. They lie abandoned, as the U.S. Patent and Trademark Office calls it, because the IRS wouldn’t pay the issue fees."

I thought that government work like this was in the public domain. Can the IRS/Treasury patent an invention?

[+] webmaven|5 years ago|reply
You're mistaking copyright and patents.

In principle, issuing patents on government developed technology isn't contradictory to their core purpose, which is to ensure public disclosure of inventions rather than keeping them as trade secrets. It certainly helps establish prior art, which is no bad thing, even for software patents.

I'm not sure whether the US government then ever exercises their option to restrict competing implementations of the technology for the life of the patent.

OTOH, the government produced implementation itself is public domain, as you noted, and not subject to copyright.

In theory, this might make patented government software freely copyable (if released), including into collective works of other software, but unforkable due to patents, even though its public domain status WRT copyright allows derivative works.

[+] pstrateman|5 years ago|reply
That sounds like they wrote a tool to convert assembly into Java....

I don't exactly have high hopes for that.

Am I missing something?

[+] himinlomax|5 years ago|reply
I remember reading about a company writing a Cobol to Java translator to migrate their codebase over 10 years ago. It seems it was very successful. They had focused on making the conversion entirely automatic and reliable, so that they could keep on retranslating new / modified Cobol code during the transition process.
[+] redis_mlc|5 years ago|reply
Sounds ugly, but if it's important enough and you have somebody who understands all the angles, it could be possible.

That excludes 99.999% of government employees, though.

[+] happymellon|5 years ago|reply
Didn't Micro Focus already do something like this, to allow legacy systems to be retired without needing software rewrites?
[+] caetris1|5 years ago|reply
If there was any way to translate the legacy code running on mainframes into a Java application, naturally, there would be an infrastructure migration issue. The new plan plainly states that the infrastructure is dependent on: "Establish Cloud Management Office and Cloud Governance", which also depends on installing the new "Procure and deliver ECM Release 1 Cloud platform on Treasury Cloud".

This stuff takes a lot of time and they've been preparing for the change since 2015. This is entirely not simple.

https://www.irs.gov/pub/irs-utl/irs_2019_integrated_moderniz...

See page 29 for details.

[+] jonnypotty|5 years ago|reply
I love how assembler code is compared to a steam engine. We literally think old code is bad because its old.
[+] bsdubernerd|5 years ago|reply
The entire industry is broken regarding this fact.

Old tested/working software developed for 10 years, dozen contributors spanning the entire history but with a last commit older than 12 months on github? Dead project. Heck reading on HN I've seen this comment even for projects having commits longer than 6 months!

People will favor a buggy/featureless project with a single lead dev all the time, just based on this.

[+] redis_mlc|5 years ago|reply
The article is incoherent to IT experts, but it's generally a good thing to bring issues to light.

tl;dr: the IRS wants to convert its assembly language software to Java, but not badly enough to actually finish it after 20+ years.

Advice to IRS: since you have somebody who understands the issues, Jian Wang, incentivize him to do it - while that option is available.

I've done transitions like what's mentioned in the article. It takes somebody to understand and shoulder huge risk, while being a target of naysayers who won't do the same. There are very few people who will do that, especially in government, when you simply don't have to assume any risk.

[+] aejnsn|5 years ago|reply
Why port a system from 40 years ago? I cannot imagine those systems are built with flexibility to endure policy changes of today.
[+] noobermin|5 years ago|reply
Can someone enlighten me? Is Java really the best choice for this? I guess it's too late at this point but I'm still curious.
[+] andrewstuart2|5 years ago|reply
Consider that this effort started 20 years ago, and also consider that if you want to hire a general backend developer today for a reasonable price, Java is the language to pick.
[+] cyberdrunk|5 years ago|reply
Java is the safest bet if you want to write something that will be maintainable at reasonable cost through the next 50 years.
[+] caetris1|5 years ago|reply
They decided on Java and .NET because they needed to hire contractors in DC that had those skills.
[+] russellbeattie|5 years ago|reply
What's weird is that every 5-10 years, a normal operation that isn't growing exponentially or anything, can easily fit all their digital stuff into another system that's faster, bigger and cheaper. Usually by so much that it offsets the cost of upgrading. The IRS must have experienced a half dozen of these cycles. Can't they just do it all on an Excel spreadsheet running on a disused workstation in the back room by now?
[+] londons_explore|5 years ago|reply
I hope they do more... The basic task is collecting the taxes. The hard task is making sure nobody is illegally paying less tax than they should.

That hard task is one where you can throw in more data and compute and get out more accurate lists of people to investigate. Whereas 50 years ago, people might be investigated nearly at random, I hope that today's investigation decisions are based on credit card statements, bank statements, lists of people who have purchased property, shares, details of company directorships, etc.

That's a lot more data from a lot more sources, which has to be fuzzy matched by name - I can imagine why these systems are still big, complex and slow.

[+] eximius|5 years ago|reply
> In FY 2019, the IRS plans to cut 2,200 employees.[1] In Rettig's FY 2020 budget request, he plans to cut an additional 1,800 employees. Since FY 2010, staffing decreased by about 19 percent, primarily in compliance and enforcement.[2]

Sounds like the current administration doesn't want a functioning IRS. Less government, less money, less enforcement for those who can avoid obvious fraud. It is everything the current administration wants.

[1] - https://www.govexec.com/management/2018/05/irs-defends-budge... [2] - https://home.treasury.gov/system/files/266/02.-IRS-FY-2020-C...

[+] dragonwriter|5 years ago|reply
> Sounds like the current administration doesn't want a functioning IRS.

The current administration, and Republicans in Congress for about 20 years before the current administration, including when they had majorities in one or both Houses.

[+] ilaksh|5 years ago|reply
Isn't it fairly well accepted at least by some factions that the tax code needs to be entirely simplified and rewritten?

So maybe there doesn't need to be a translation of the old system. But rather a totally new one that could be much more easily created from scratch. In public, on GitHub or something. In a modern programming language. Possibly attached to an Ether-based US cryptodollar.

Do Chinese taxes interface at all with their new digital currency?

[+] kelnos|5 years ago|reply
> Isn't it fairly well accepted at least by some factions that the tax code needs to be entirely simplified and rewritten?

Unfortunately not the factions with the power to effect change. The tax prep industry loves a complicated tax code, and spends a lot every year lobbying to keep things complicated and keep the government from preparing our taxes for us. The rich prefer a complicated tax code with loopholes that help them legally hide income from taxation. Some of them are Congresspeople, or at the very least are campaign donors.

> So maybe there doesn't need to be a translation of the old system. But rather a totally new one that could be much more easily created from scratch. In public, on GitHub or something. In a modern programming language.

I don't think there'd ever be the political will to start from scratch here, even if that might be the best thing. So we're stuck with what we have, and the legacy system likely has a lot of un- or poorly-documented behavior in it such that it's safer to translate it into a higher-level language where there's more expertise at hand to deal with extending and modernizing it.

[+] dragonwriter|5 years ago|reply
> Isn't it fairly well accepted at least by some factions that the tax code needs to be entirely simplified and rewritten?

Yes, by “some factions”. But even among those factions, there's no consensus on the basic goals such a simplification and rewriting should be guided by, so there's no strong base of support for any particular fundamental change, even among those who would embrace the idea that fundamental change is needed.

[+] aejnsn|5 years ago|reply
When we have companies like Intuit lobbying for complexity, this is what we have.
[+] vegesm|5 years ago|reply
I think they also need the historical rules kept for whatever reporting/cross checking it is needed. So essentially they would have to rewrite the rules of the last 40-50 years.