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?
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.
Just FYI for next time, there is a two hour edit window on HN comments, and no one minds if you update a comment with added thoughts.
Either way, thank you for the interesting comment(s)!
(At the risk of going too far afield, some feel that you should add an "EDIT:" note for any changes to a comment, but my personal feeling is that it's cool to simply edit without calling extra attention to the edit, especially when the edit doesn't significantly change the meaning.)
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.
I am not referring to some sort of gateway, ESB, etc. I am referring to the patent application, which would be for a tool to port code from Assembly to another target language, the example they used being Java.
I'm not sure what ALB assembly is, but I do know disassemblers themselves are kinda rare (which this really isn't either; more of a disassembler+transpiler). On top of that, whatever ALB assembly is, it kinda sounds like there might be only a market of one or two places in the world using it.
Remember, they're saying these systems were put in place in the 60s and 70s. In 1960, COBOL was the new hotness -- modern day Go has 5 years more maturity than COBOL had in 1960, and there was no internet yet. Even ARPANET wouldn't be invented for another 9 years. Whatever was being written back then was not written by developers with the kind of access to information we have today. And definitely not with the kind of storage luxury we have today that permit us to document and comment as copiously as we want to.
ALC (mentioned in the patent) is Assembly Language Coding, referring to various IBM mainframe assemblers.
Disassemblers aren't rare, and certainly exist for the CPUs in question. But the patent is trying to produce structured Java code from handwritten assembly, which is definitely not something for which many OTS solutions exist.
> tens or hundreds of thousands of HR systems, paper forms, tax laws, jurisdictions, edge cases, bank transfers, etc,
Is there any evidence that this is the case though? I don’t have any evidence for the contrary either, but my own experience would suggest that the IRS system is likely bulky and inflexible behemoth that does not care least to be compatible with any other systems as all of those other systems are written to be compatible with what IRS have already. And whatever edge cases or gotchas there might be they are probably offloaded to internal bureaucracy.
> 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.
> 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.
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.
Because a lot of business logic is probably hard coded and undocumented. Porting it moves it to a platform/language that may be better suited to continuing operations or applying the strangler pattern.
You're probably right. This problem just hits different in my mind because implementation is outlined in the IRC. If using the past is any way of predicting the future, I would imagine a history of bills and policy changes could indicate levels of necessary flexibility and where. I am looking at this with rose-colored glasses. :)
Because the IRS Masterfile is hard. Nobody alive today knows how it all works and 99.9% of coders have no experience with something that complicated.
At the IRS, when the screen said one thing and the docs and regs said another, the software was right. Every time someone filled out the paperwork thinking theyd found a bug, a couple months later a letter came back with 20 years of tax code citations showing why you were wrong.
We only found bugs in the software for new tax programs.
That isn't going to happen in the US because all those loopholes represent some politician flexing his power. No, I'm not exaggerating.
I think in some of the Nordic countries they've done harmonization, but that can only occur when a technical solution is possible, and US politician want to retain political control of funding.
Don't get me started about AMT. About a decade ago there was a poll of House members. All of them said they couldn't do their own taxes because of AMT, except one who was basically poor.
For non-US readers, the US federal tax code consists of 2 parallel rules, regular and Alternative Minimum Tax (AMT). AMT was originally supposed to catch high-income earners, but after decades of inflation, catches basically anybody with a 6-figure salary, depending on the tax year.
Simplification results in a more just system, and it is entirely possible to lower tax while increasing tax revenue for the state (I think Sweden did this, can't find citation ATM).
Because the 3 to 4 previous attempts (depending on how you count) over 5 decades costing tens of billions of today's dollars all failed to replace it[1]. Not that machine translation has been breakthrough panacea either, apparently, but at least they've shown enough flexibility to try a pragmatic approach.
> Why port a system from 40 years ago? I cannot imagine those systems are built with flexibility to endure policy changes of today.
Because (1) you need access to data in the legacy system, from which exports are nontrivial and require understanding of the structure and flow of the system, because it's very much not a relational DB or other application-neutral datastore, (2) big-bang replacements of systems like this have a near-100% history of catastrophic, embarrassing failure that get lots of major media coverage and ends careers, so you need a way to port the existing system to a platform that is supportable long enough to make Ship of Theseus replacement viable,
It’s not immediately clear what benefits that would bring though besides ticking a box of “technically a modern language”. Automated translation won’t be much more readable than assembly and it won’t magically become enterprise grade OOP either.
According the the article, they want to move from a local environment using assembler to Java, which apparently gives them a direction for network access, including web.
You don't think it's easier to develop in Java than assembly? And setting aside the development experience, it might be easier to hire Java programmers.
From experience, i have seen cobol code stashing entire copybooks into char/varchars, along with some binary switches to select the appropriate copybook. Unless you have the copybook or a translated version, it's pretty much unreadable.
In general it's useful if only to interface with those old parts you don't want or can't change.
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.
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?
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.
> 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.
Not directly, but since the Bayh-Dole Act (1980) as a matter of Federal policy contractors can retain ownership of patents and the government routinely grants exclusive licenses to federal employee inventions. See https://en.wikipedia.org/wiki/Bayh%E2%80%93Dole_Act
I've been aware for several years of contractors generally retaining ownership of the federally funded IP they produce as long as the federal government gets a perpetual licence, but not of the government granting exclusive licences to federal employee inventions. Do you have examples?
I guess I overstated the case. AFAIU the intent was for the government to push for commercialization of its inventions using exclusive and non-exclusive licensing agreements. See, e.g.,
Perhaps federal employee inventions are typically for basic research and don't lend themselves to direct commercialization. And while use of those basic science patents might be necessary for actual commercial products, nobody in the government is policing infringement--which is probably a good thing. By contrast, even when a federal contractor is doing basic research, they have more financial incentive to aggressively file patents and subsequently enforce them.
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?
> 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.
> 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.
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.
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.
Java licencing is manageable compared to the cost of developing a human resurrection technology in 2100 to bring back to life developers of by then long-forgotten technologies, which were hip in 2020. I bet Java will still be doing fine in 2100. Furthermore, the support of a behemoth such as Oracle is very reassuring for large businesses, which know that they won't be left alone with their tech stack. Can the same thing be said about Python or Scala?
There's an unimaginable amount of business critical code written in Java already. Java is seen by businesses as good enough, so, barring some breakthroughs in CS, there will not be much pressure to migrate off it. And even if there were (let's say Oracle starts charging unreasonably much for Java, the way IBM does for mainframes), we can still see plenty of COBOL/MF architectures in the wild today.
Given that they're rewriting something that was 40 years old 20 years ago tells me that it might be an impossible task given the current attitude of software development as a whole.
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.
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 .
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.
Just a datapoint: I (And lots of other people) could readily build and maintain a team of software engineers for $109-$134k salary in the Midwest that would be fully competent in achieving anything the irs needed.
I’m confident that that’s true in the “bulk construction” aspect of the project, which is of course an enormously important component of the task.
I’m not at all convinced that that’s true for the architecture and strategic planning aspect of how to tackle the project. (I’m talking about industry salary rate for top leaders and architects here; I’m not suggesting that people with this profile aren’t available in the Midwest; I’m merely stating that they could make wildly more than $134K in industry even in the worst-paid Midwest city.)
I don't know what he's making nowadays, but the IRS -does- have developers in the midwest (Michigan). A colleague I went to college with actually wound up getting a job with them after college. At the time the pay wasn't 'great' but the pension looked good.
OTOH, this was in 2007, so if nothing else he had stability during those times.
Although, it was COBOL... that said, they didn't require any COBOL experience and he spent his first 2-3 months training.
This is one of the strategies which 18F pursues: either remote work or working out of offices around the country is much less of a losing game than trying to match DC/SF salaries directly. It’s not perfect but given that the DC salary cap can’t be lifted without the Vice President and Congress getting raises it’s a lot more in their control.
Was just reading about the Norwegian Police which is trying to get a new IT director[1]. The police is in dire need of updating several old and complex IT solutions, and need someone good to help them through this process.
Some are very upset that the salary is so high, about 3x what regular police officers are making. One quote was "The Labor Party cannot accept that our police officers earn less than half of what the police directors do".
On the one hand I kinda agree as they don't seem to have any significantly larger responsibility in practice (if they screw up they don't pay for their mistakes), and well, the actual job is done by the team.
On the other hand... if you're good at what you're doing then there can be lots of interesting places to work, and more money certainly makes life easier.
A Labor party should understand that the ability to organize and direct the labor of workers is itself exceptionally valuable labor. The value even scales up with the number of workers involved, the locations involved, the number of other working relationships that must be managed, and so on.
I understood some things better once I started thinking of management as organization workers.
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.
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?
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.
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.
The signal is very much not that software with no commits is bad, it's just very common to have half-finished projects or very buggy packages which are no longer maintained. I'd say the quantity of those greatly outweighs the quantity without relatively recent commits which are good. This means that, as a very coarse heuristic, it's probably a good idea to be fairly skeptical of projects without somewhat recent commits, if only they're to keep up with the latest npm update or whatever.
78 comments
[ 3.7 ms ] story [ 126 ms ] threadFurthermore, why did the IRS spend time and salaries to reinvent the wheel for a solution that is likely to exist as an OTS product?
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.
Either way, thank you for the interesting comment(s)!
(At the risk of going too far afield, some feel that you should add an "EDIT:" note for any changes to a comment, but my personal feeling is that it's cool to simply edit without calling extra attention to the edit, especially when the edit doesn't significantly change the meaning.)
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.
Remember, they're saying these systems were put in place in the 60s and 70s. In 1960, COBOL was the new hotness -- modern day Go has 5 years more maturity than COBOL had in 1960, and there was no internet yet. Even ARPANET wouldn't be invented for another 9 years. Whatever was being written back then was not written by developers with the kind of access to information we have today. And definitely not with the kind of storage luxury we have today that permit us to document and comment as copiously as we want to.
Disassemblers aren't rare, and certainly exist for the CPUs in question. But the patent is trying to produce structured Java code from handwritten assembly, which is definitely not something for which many OTS solutions exist.
Is there any evidence that this is the case though? I don’t have any evidence for the contrary either, but my own experience would suggest that the IRS system is likely bulky and inflexible behemoth that does not care least to be compatible with any other systems as all of those other systems are written to be compatible with what IRS have already. And whatever edge cases or gotchas there might be they are probably offloaded to internal bureaucracy.
That's a good indicator that the system is being actively maintained.
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...
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.
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.
At the IRS, when the screen said one thing and the docs and regs said another, the software was right. Every time someone filled out the paperwork thinking theyd found a bug, a couple months later a letter came back with 20 years of tax code citations showing why you were wrong.
We only found bugs in the software for new tax programs.
I think in some of the Nordic countries they've done harmonization, but that can only occur when a technical solution is possible, and US politician want to retain political control of funding.
Don't get me started about AMT. About a decade ago there was a poll of House members. All of them said they couldn't do their own taxes because of AMT, except one who was basically poor.
For non-US readers, the US federal tax code consists of 2 parallel rules, regular and Alternative Minimum Tax (AMT). AMT was originally supposed to catch high-income earners, but after decades of inflation, catches basically anybody with a 6-figure salary, depending on the tax year.
If you want your head to explode, read this:
https://en.wikipedia.org/wiki/Alternative_minimum_tax
Simplification results in a more just system, and it is entirely possible to lower tax while increasing tax revenue for the state (I think Sweden did this, can't find citation ATM).
Because the 3 to 4 previous attempts (depending on how you count) over 5 decades costing tens of billions of today's dollars all failed to replace it[1]. Not that machine translation has been breakthrough panacea either, apparently, but at least they've shown enough flexibility to try a pragmatic approach.
[1] https://spectrum.ieee.org/riskfactor/computing/it/irs-predic...
Because (1) you need access to data in the legacy system, from which exports are nontrivial and require understanding of the structure and flow of the system, because it's very much not a relational DB or other application-neutral datastore, (2) big-bang replacements of systems like this have a near-100% history of catastrophic, embarrassing failure that get lots of major media coverage and ends careers, so you need a way to port the existing system to a platform that is supportable long enough to make Ship of Theseus replacement viable,
https://federalnewsnetwork.com/tom-temin-commentary/2018/01/...
I don't exactly have high hopes for that.
Am I missing something?
That excludes 99.999% of government employees, though.
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?
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.
Not directly, but since the Bayh-Dole Act (1980) as a matter of Federal policy contractors can retain ownership of patents and the government routinely grants exclusive licenses to federal employee inventions. See https://en.wikipedia.org/wiki/Bayh%E2%80%93Dole_Act
https://www.law.cornell.edu/uscode/text/15/3710 (sister legislation to Bayh-Dole: https://en.wikipedia.org/wiki/Stevenson-Wydler_Technology_In...)
https://www.doi.gov/techtransfer/patents
https://www.nist.gov/tpo/incentives-inventors
https://www.energy.gov/sites/prod/files/2015/01/f19/Licensin...
But I couldn't find much evidence that this is common. In fact, this 2017 accounting of royalty payments to federal employee inventors suggests it's not common at all: https://www.whitehouse.gov/wp-content/uploads/2017/12/10-20-...
Perhaps federal employee inventions are typically for basic research and don't lend themselves to direct commercialization. And while use of those basic science patents might be necessary for actual commercial products, nobody in the government is policing infringement--which is probably a good thing. By contrast, even when a federal contractor is doing basic research, they have more financial incentive to aggressively file patents and subsequently enforce them.
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?
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.
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.
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.
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.
I’m not at all convinced that that’s true for the architecture and strategic planning aspect of how to tackle the project. (I’m talking about industry salary rate for top leaders and architects here; I’m not suggesting that people with this profile aren’t available in the Midwest; I’m merely stating that they could make wildly more than $134K in industry even in the worst-paid Midwest city.)
I don't know what he's making nowadays, but the IRS -does- have developers in the midwest (Michigan). A colleague I went to college with actually wound up getting a job with them after college. At the time the pay wasn't 'great' but the pension looked good.
OTOH, this was in 2007, so if nothing else he had stability during those times.
Although, it was COBOL... that said, they didn't require any COBOL experience and he spent his first 2-3 months training.
Some are very upset that the salary is so high, about 3x what regular police officers are making. One quote was "The Labor Party cannot accept that our police officers earn less than half of what the police directors do".
On the one hand I kinda agree as they don't seem to have any significantly larger responsibility in practice (if they screw up they don't pay for their mistakes), and well, the actual job is done by the team.
On the other hand... if you're good at what you're doing then there can be lots of interesting places to work, and more money certainly makes life easier.
[1]: https://www.dagbladet.no/nyheter/hinsides/72570672
I understood some things better once I started thinking of management as organization workers.
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.
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.
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.
Code that has dozens of dependencies is a whole other matter.
I had to bring in a 5 year old, since last commit, library. On its on it was fine. But the dependencies were a massive pain.