The IRS’s Effort to Convert Its Assembly Codebase to Java(federalnewsradio.com)
federalnewsradio.com
The IRS’s Effort to Convert Its Assembly Codebase to Java
https://federalnewsradio.com/tom-temin-commentary/2018/01/irs-clutches-its-modernization-holy-grail/
223 comments
The big trick is the proposal itself. Writing that is only possible if you are already tied in at all kinds of levels. I've seen some of these tenders up close, the companies that land the deals submit phone book sized proposals to tenders that are officially open but actually closed unless you are in a very select circle already. It's not uncommon for the proposal writer to then pass on the actual work to a whole slew of subcontractors at substantially lower rates.
Thanks, I suspected that this was the case after I read the Cringely book on IBM (https://www.amazon.com/Decline-Fall-IBM-American-Icon-ebook/...). It gives one the distinct impression that connections matter a lot, and that getting the contract matters more than actually completing it successfully.
This is too true.
The career path at my former defense contracting gig went from software engineer to someone who writes proposals. They clearly valued winning work over executing it. Rent seeking economics at work.
The career path at my former defense contracting gig went from software engineer to someone who writes proposals. They clearly valued winning work over executing it. Rent seeking economics at work.
This applies to all big corporations, not only government related projects.
Almost no one wins submitting proposals out of the blue, certainly the case with unsolicited proposals but also with responses to formal RFPs. Firing in a proposal with no agency contact, no familiarity ("customer intimacy"), no shaping, no premarketing, no office calls, no digging to understand their real pain points is even worse than a cold call because, as you noted, it is horrendously more expensive and painful to prepare a large proposal.
Are you saying this is how contracts are awarded on FedBiz Ops?
I know a handful of small players, myself included who have won IT contracts with the gov't and it is not at all like you stated.
I know a handful of small players, myself included who have won IT contracts with the gov't and it is not at all like you stated.
Small contracts are an entirely different matter. Try bagging something >> $1M or defense related.
I've worked for the government on small jobs here in the EU a couple of times, as long as you stay below a certain amount you can bypass a ton of requirements. But once you go above that threshold the number of players drops very rapidly and there is no escaping the formal process.
If you are capable of selling large contracts to the US Federal Government without having to submit a typical bid proposal then you are in a very fortunate position, but the people that I know that have done this in the past have all worked on stuff that either required their fairly unique skills or they were working on extremely small contracts (< $250K).
I've worked for the government on small jobs here in the EU a couple of times, as long as you stay below a certain amount you can bypass a ton of requirements. But once you go above that threshold the number of players drops very rapidly and there is no escaping the formal process.
If you are capable of selling large contracts to the US Federal Government without having to submit a typical bid proposal then you are in a very fortunate position, but the people that I know that have done this in the past have all worked on stuff that either required their fairly unique skills or they were working on extremely small contracts (< $250K).
Here is one of the two young entrepreneurs (19 and 23 years old) that secured ~$300M DoD contract. So obviously, it is not as bad. ;)
In 2005, Packouz (23 years old at the time) joined Efraim Diveroli (19 years old at the time) in Diveroli's arms company AEY Inc. By the end of 2006, the company had won 149 contracts worth around $10.5 million.[1] In early 2007, AEY secured a nearly $300 million U.S. government contract to supply the Afghan Army with 100 million rounds of AK-47 ammunition, millions of rounds for SVD Dragunov sniper rifles, aviation rockets and other munitions
https://en.wikipedia.org/wiki/David_Packouz
EDIT: added quote from Wikipedia
In 2005, Packouz (23 years old at the time) joined Efraim Diveroli (19 years old at the time) in Diveroli's arms company AEY Inc. By the end of 2006, the company had won 149 contracts worth around $10.5 million.[1] In early 2007, AEY secured a nearly $300 million U.S. government contract to supply the Afghan Army with 100 million rounds of AK-47 ammunition, millions of rounds for SVD Dragunov sniper rifles, aviation rockets and other munitions
https://en.wikipedia.org/wiki/David_Packouz
EDIT: added quote from Wikipedia
Supply contracts are very different than a bid to build something to specifications.
Pity they had to do it fraudulently. This is not exactly a bespoke product though. 4 years in jail/7 months house arrest is not a great thing to have on your record either but I guess the payday made it worth it for them.
The intestinal fortitude needed to prepare a proposal for these mega projects is enormous. I always end up with a gut churning feeling that no one is even going to read my work (which is interrupting any work on real projects), or that some back hander will result in a not level playing field.
Do people read them? If it's really a phone-sized book, I assume that there's some sort of algorithm, whether run by a person or a computer, that is just looking for things to check off a list.
Sometimes from debriefs, it is clear that they at best skimmed. Therefore the job of the proposal writer is to make the evaluator's job easy and to make the reader eager to turn the page, e.g., no walls of text just like on reddit or Hacker News.
There is no algorithm or computer looking at it. It’s essentially a contract, to be looked at by lawyers and project sponsors.
Are you saying this is how contracts are awarded on FedBiz Ops?
I do grant writing for nonprofit and public agencies, along with some research-based businesses, and people interested in getting into this sort of thing will contact us, or people like us.
We're a little like lawyers: it is possible to do everything right, but it's very hard and unlikely if it's your first rodeo.
To take one small example: when you submit a budget, is it a program budget or a total project budget? Err and your application may be disqualified. Or consider indirect cost rates: http://seliger.com/2016/05/16/federally-approved-indirect-co... .
Again, either of these things are small, but multiply them x1000 and suddenly you'll understand why organizations hire us!
I do grant writing for nonprofit and public agencies, along with some research-based businesses, and people interested in getting into this sort of thing will contact us, or people like us.
We're a little like lawyers: it is possible to do everything right, but it's very hard and unlikely if it's your first rodeo.
To take one small example: when you submit a budget, is it a program budget or a total project budget? Err and your application may be disqualified. Or consider indirect cost rates: http://seliger.com/2016/05/16/federally-approved-indirect-co... .
Again, either of these things are small, but multiply them x1000 and suddenly you'll understand why organizations hire us!
I just registered on SAM and submitted a bid (something unrelated to this), but no idea what I was doing, I mean I put together a plan, had meaningful past performance, but overall I'm just hoping for the best. Would you happen to have any resources you followed? Or, suggestions that you believe led you to submitting a successful bid?
There are Procurement Technical Assistance centers in every region of the country. They are staffed by former procurement officers, and help companies learn how to sell to government and prime contractors.
http://www.aptac-us.org/
http://www.aptac-us.org/
I was just looking into it a few hours ago, do you have a good experience with them? Just as many people on here I've been through different forms of office hours, one of them with a locally run entrepreneurship center, I saw an attorney (that was years ago before I could properly afford one). I know the guy volunteered his time, but basically what he said was "hey, give me a portion of your company, and I'll provide you with services", I came away with absolutely zero advice. That's why when I was looking into it today, I was a bit skeptical.
I saw a presentation from one of the people from the local office. Her advice seemed reasonable: Go to the procurement conferences, get a one-pager of the capabilities of your firm, and talk to the purchasing agents. See government contracting as a supplement to your business revenue, not the core.
Thank you for passing it on, I'll send them a message tomorrow.
Was your bid on the recent SBIR/STTR solicitation by chance?
Custom database product for EPA, seemed like a good fit. While I have no connections to EPA, I do some collaborative work with bio-engineering department at a university in Chicago, I'm a data scientist/developer/have a small team, I thought I'd try dipping my toes in something new.
Any technical people you were able to have discussions with in preparing your bid would be good places to start with follow-on conversations.
An acquaintance with a setup similar to yours does well with a virtuous cycle of rolling SBIR and STTR results into his commercial products, which fuel more SBIR wins. He also does lots of legwork in the form of hand delivering white papers he’s written in office calls with customers and potential customers during site visits.
People do business with people — particularly those we like, know, and trust — not companies and agencies. Find someone whose headache you can make go away. Keep the conversation moving.
This is a patient person’s game. Sometimes you’re planting seeds that will bloom later.
An acquaintance with a setup similar to yours does well with a virtuous cycle of rolling SBIR and STTR results into his commercial products, which fuel more SBIR wins. He also does lots of legwork in the form of hand delivering white papers he’s written in office calls with customers and potential customers during site visits.
People do business with people — particularly those we like, know, and trust — not companies and agencies. Find someone whose headache you can make go away. Keep the conversation moving.
This is a patient person’s game. Sometimes you’re planting seeds that will bloom later.
I'm sure you are aware of the 8a and other programs that allow you to win small contracts.
If you think big projects are given on merit, then you are naive.
If you think big projects are given on merit, then you are naive.
This seems like a problem of trust and the IRS has already chosen whom it trusts based on past work done etc. Seems unfair, but how would you be able to trust someone whom you’ve never done business with earlier? Could these be translated to laws to prevent this type of exclusion?
> If the government is worried about trojans, malware, etc., then they can easily hire an auditor to audit the code and vouch for its authenticity.
Not that I disagree with the general idea of democratizing this sort of big government contract, but, well, this is a much bigger hurdle than you are making it sound like. Audits can be good at finding unintentional flaws, but a skilled adversary can often create code that looks safe, but in fact, isn't. Consider the underhanded C contest: http://www.underhanded-c.org/
On a personal note: I once worked on a large research project for detecting malicious behavior on Android apps, where the idea was to produce tooling to find underhanded/undocumented behavior automatically. The project had a red team. By the final rounds, we were getting code from them where the malicious functionality was extremely hard to find via either tooling or manual inspection. Keep in mind these were simple programs, rarely over 10k lines of code, written in Java which is a remarkably transparent language to read, and that we were allowed to ban features like reflection or raise the alarm on anything that looked like intentionally obfuscated code. Additionally, we knew each of those programs had malware in them. Reporting 'clean' was often just saying 'you win, we give up, couldn't find it after staring at this 2k lines file for a week'.
In theory, when working with a large contractor, you can put controls on how the software is built, not just the final code, and you can hold them accountable for backdoors discovered long after the fact. Now, not saying this always works that way, but it might still be better than accepting a system built by someone you only know from their Github handle and who might or might not live within your jurisdiction. The state of the art in software verification would need to change a great deal before that is a good idea.
Not that I disagree with the general idea of democratizing this sort of big government contract, but, well, this is a much bigger hurdle than you are making it sound like. Audits can be good at finding unintentional flaws, but a skilled adversary can often create code that looks safe, but in fact, isn't. Consider the underhanded C contest: http://www.underhanded-c.org/
On a personal note: I once worked on a large research project for detecting malicious behavior on Android apps, where the idea was to produce tooling to find underhanded/undocumented behavior automatically. The project had a red team. By the final rounds, we were getting code from them where the malicious functionality was extremely hard to find via either tooling or manual inspection. Keep in mind these were simple programs, rarely over 10k lines of code, written in Java which is a remarkably transparent language to read, and that we were allowed to ban features like reflection or raise the alarm on anything that looked like intentionally obfuscated code. Additionally, we knew each of those programs had malware in them. Reporting 'clean' was often just saying 'you win, we give up, couldn't find it after staring at this 2k lines file for a week'.
In theory, when working with a large contractor, you can put controls on how the software is built, not just the final code, and you can hold them accountable for backdoors discovered long after the fact. Now, not saying this always works that way, but it might still be better than accepting a system built by someone you only know from their Github handle and who might or might not live within your jurisdiction. The state of the art in software verification would need to change a great deal before that is a good idea.
I don't suppose those Java examples were published? I'd love to see them.
How about a nice, simple, 2 + 2 = 5? https://codegolf.stackexchange.com/a/28818
Unfortunately, I don't believe they were.
I agree, it's a thorny technical issue, for sure.
My thinking is that the issue isn't actually technical, but one of risk management, and that's something that markets are very good at dealing with. I would guess that there would be quite a few companies out there willing to step in and certify/insure code quality, for the right price.
Of course, DOD and other more sensitive systems are a completely different animal with respect to risk, so this wouldn't necessary apply there.
My thinking is that the issue isn't actually technical, but one of risk management, and that's something that markets are very good at dealing with. I would guess that there would be quite a few companies out there willing to step in and certify/insure code quality, for the right price.
Of course, DOD and other more sensitive systems are a completely different animal with respect to risk, so this wouldn't necessary apply there.
I would disagree. On of my first jobs was porting assembler to C for a paging switch. The assembler was well written and well documented. The task was slow, hard and painfully boring. It took months to get every function to be a perfect match.
Manually, sure, but it sounds like the idea is/was to use an automated approach. I imagine many of the same techniques used by modern decompilers could be applied, and there's probably lots of information in assembly that is lost in machine code (e.g., JE vs JZ on x86). One could also assume some knowledge of the coding conventions used by the organization. Even a tool that could translate 90% automatically, leaving the rest to be done manually, would work out pretty well.
In some ways it reminds me of the project to programatically translate the golang compiler from C to Go. Though I imagine the codebase is quite a bit messier!
In some ways it reminds me of the project to programatically translate the golang compiler from C to Go. Though I imagine the codebase is quite a bit messier!
Did you manually convert the assembler, or automate it ? With regard to manual conversions, I'm with you 100% - no thanks. :-)
But, my understanding is that the bulk of the work done in this case was done by a conversion tool that was designed and developed by a group of 8 people led by the gentleman referred to in the article (Jian Wang). The conversion tool project was the work that I was referring to in my comment.
But, my understanding is that the bulk of the work done in this case was done by a conversion tool that was designed and developed by a group of 8 people led by the gentleman referred to in the article (Jian Wang). The conversion tool project was the work that I was referring to in my comment.
Yes, manually. I missed that distinction, building the tool could be fun, but verifying it works would be a huge pain. Shouldn't be too hard to write test cases for tax code.
> Shouldn't be too hard to write test cases for tax code.
I would disagree here -- like timezones, tax software has the disadvantage of being both extremely boring, and very fiddly (thus requiring close attention). This combination makes it very hard to maintain the concentration that's required to write exhaustive tests.
I would disagree here -- like timezones, tax software has the disadvantage of being both extremely boring, and very fiddly (thus requiring close attention). This combination makes it very hard to maintain the concentration that's required to write exhaustive tests.
Different strokes. Although, given a long enough period of working through assembly it might break the strongest of wills. I can imagine some people being very excited at setting up tests to ensure compatibility and watching them slowly going from fail to pass.
Rather than transcode assembly to a higher-level language. It's better to nail down all the functionality the assembly program provide and re-implement them in the higher-level language. Write language independent tests against the old code and re-run the tests against the new code to make sure things are working feature for feature and bug for bug.
This suggestion is pretty innocent of practical knowledge of the problem.
Simply extracting the control structure of the assembly via automation is a huge win. This type of assembly is incredibly dense - it was written for machines with at most, 100's of K of memory. It relies on highly non-local side effects which are very dependent on the data.
Things like a reference to a status register bit that was possibly set as a side effect of an instruction 30 or 40 instructions back, but then could have been modified by three or more other instructions, none of which are control flow instructions. All depending on knowing that certain patterns do/do not ever appear in the data.
After the control flow is extracted and made visible, then you can get to things like numerical emulation of the exact oddities of S360 code.
Once you have all those things done, which you will not ever, ever, be able to do by hand, then you can take the resulting generated Java and begin re-implementing.
The work being described has to happen before the suggestion above can even be approached.
Simply extracting the control structure of the assembly via automation is a huge win. This type of assembly is incredibly dense - it was written for machines with at most, 100's of K of memory. It relies on highly non-local side effects which are very dependent on the data.
Things like a reference to a status register bit that was possibly set as a side effect of an instruction 30 or 40 instructions back, but then could have been modified by three or more other instructions, none of which are control flow instructions. All depending on knowing that certain patterns do/do not ever appear in the data.
After the control flow is extracted and made visible, then you can get to things like numerical emulation of the exact oddities of S360 code.
Once you have all those things done, which you will not ever, ever, be able to do by hand, then you can take the resulting generated Java and begin re-implementing.
The work being described has to happen before the suggestion above can even be approached.
you could also just dust off the original specification. code up whatever it's supposed to do, then special case all of the junk that doesn't match.
There rarely is an original specification, and even if one exists, what was actually written has a high probably of not actually matching the specification exactly because of undocumented feature requests or additions.
You did read the bit that said the current system is the accumulation of almost 60 years of changing tax legislation, right?
Yeah, ~30 year projects were the longest i've ever worked on. Sometimes it's easier to read the docs about what the old programmers were trying to do - those telephone sized documents explaining requirements. if you're lucky, they might have started using source control in the 90's and you can kinda match up specs to commits.
> you could also just dust off the original specification.
You must be new here. What specification? Oh dear.
You must be new here. What specification? Oh dear.
> nail down all the functionality the assembly program
This often proves to be much harder than expected which is /why/ people almost never touch systems like this where the creators are long gone
This often proves to be much harder than expected which is /why/ people almost never touch systems like this where the creators are long gone
It's the most difficult part of the project. However, nailing down the functionality upfront separates a successful project from a failed one. The implementation is the easy part. The functionality documentation will provide great value beyond this project.
I assume this assembly program does the tax calculation, so the IRS tax code can be consulted to verify the functionality. Functional tests can be written against the old code as the functionality is documented. The functional tests will guide the new implementation development, and serve as the acceptance tests of the new code.
You can even structure the process such that there's a team doing just the functional specification and functional test writing, and another team takes the result fed to them and does the implementation in parallel.
I assume this assembly program does the tax calculation, so the IRS tax code can be consulted to verify the functionality. Functional tests can be written against the old code as the functionality is documented. The functional tests will guide the new implementation development, and serve as the acceptance tests of the new code.
You can even structure the process such that there's a team doing just the functional specification and functional test writing, and another team takes the result fed to them and does the implementation in parallel.
> It's the most difficult part of the project. However, nailing down the functionality upfront separates a successful project from a failed one.
Yes, in that projects which try to reimplement large existing systems from the ground up by nailing down the requirements and working from there, almost invariably fail (even if they formally “succeed” in the sense of being accepted and then facing years of remediation.)
You always want to do a Ship of Theseus replacement rather than all-at-once, if possible, and finding a way to lift-and-shift the existing implementation to a platform that supports the way you'd like to replace thing in the long term is a way of getting as close as possible to that when you can't practically do it directly.
Yes, in that projects which try to reimplement large existing systems from the ground up by nailing down the requirements and working from there, almost invariably fail (even if they formally “succeed” in the sense of being accepted and then facing years of remediation.)
You always want to do a Ship of Theseus replacement rather than all-at-once, if possible, and finding a way to lift-and-shift the existing implementation to a platform that supports the way you'd like to replace thing in the long term is a way of getting as close as possible to that when you can't practically do it directly.
> Ship of Theseus replacement
This why java seems an odd choice; I can't imagine trying to run a codebase that's a split between assembly and java (keeping behaviour the same as more and more code is shifted).
The best idea I can see for that, is start with an interpreter for the assembler in java, moving procedure calls "up" into java.
But I imagine getting the interpreter good enough to run the same as the original target machine would be a huge task in itself.
[ed: leveraging clojure on the first iteration(s) might actually make the project feasible, though...]
This why java seems an odd choice; I can't imagine trying to run a codebase that's a split between assembly and java (keeping behaviour the same as more and more code is shifted).
The best idea I can see for that, is start with an interpreter for the assembler in java, moving procedure calls "up" into java.
But I imagine getting the interpreter good enough to run the same as the original target machine would be a huge task in itself.
[ed: leveraging clojure on the first iteration(s) might actually make the project feasible, though...]
ha, this is clever!
I imagine you might get the interpreter running up to spec by flipping actual mainframe to debug, then writing a supervisor at the interpreter's side that checks for parity at each instruction, then single-steps the physical machine.
I imagine you might get the interpreter running up to spec by flipping actual mainframe to debug, then writing a supervisor at the interpreter's side that checks for parity at each instruction, then single-steps the physical machine.
> Ship of Theseus replacement
Love it. It appears engineers have resolved that particular philosophical dilemma with "yes" :P
Love it. It appears engineers have resolved that particular philosophical dilemma with "yes" :P
> It's the most difficult part of the project
I'll agree with that heartily.
> the IRS tax code can be consulted to verify the functionality
You're not wrong, but the problem is often not that. The tax code helps when verifying the system end to end. But it's not like there's one single program that "does the tax" that you can verify that way.
The individual bits they're trying to replace are probably more like "fetch all these records from this one mainframe with format X and convert them this way, except if it's Feb 29th in which case fetch it from this other server and convert it another way and then pass it along, except for resident aliens which come from an entirely different place, fetch those from tape storage". This is much harder to get right without formal specs, which there almost certainly aren't.
In this case what we have is a "reference implementation" (a.k.a the implementation is the specification), and you can guess how well those go.
All this is not to say that they shouldn't have been doing what you're suggesting, but to say that you're making it sound easier than it is now that they're here.
I'll agree with that heartily.
> the IRS tax code can be consulted to verify the functionality
You're not wrong, but the problem is often not that. The tax code helps when verifying the system end to end. But it's not like there's one single program that "does the tax" that you can verify that way.
The individual bits they're trying to replace are probably more like "fetch all these records from this one mainframe with format X and convert them this way, except if it's Feb 29th in which case fetch it from this other server and convert it another way and then pass it along, except for resident aliens which come from an entirely different place, fetch those from tape storage". This is much harder to get right without formal specs, which there almost certainly aren't.
In this case what we have is a "reference implementation" (a.k.a the implementation is the specification), and you can guess how well those go.
All this is not to say that they shouldn't have been doing what you're suggesting, but to say that you're making it sound easier than it is now that they're here.
That’s actually not true. I work for a fairly small contractor (a few hundred people) working on a fairly large government contract. It started with a handful of people when the company was a fraction of the size.
I'm very happy to be proven wrong. I must admit that I know very little about the process, other than what I've read, and what I've read hasn't been positive. But, I'm sure that small, successful projects aren't talked about nearly as much in the press as large, unsuccessful projects, so it could simply be bias in what I'm reading.
Lobbyists usually thwart any opportunity for someone cheap and legitimate to do the job. They've been trying to get someone to replace the humvee for decades and usually it's a 400 million dollar endeavor that results in a lesser product.
It's like these large companies take on the work, then instead of doing it they hire lawyers to figure out loopholes in the contract. Then they just pay lobbyists to get politicians to award them more contracts. All the while doing just enough to not get sued into oblivion.
All great ideas are spoiled by great bureaucrats and even greater lobbyists.
It's like these large companies take on the work, then instead of doing it they hire lawyers to figure out loopholes in the contract. Then they just pay lobbyists to get politicians to award them more contracts. All the while doing just enough to not get sued into oblivion.
All great ideas are spoiled by great bureaucrats and even greater lobbyists.
> working out the logic flows in assembler
Not only assembler, but IBM mainframe assembler. That's way cooler than x86.
Not only assembler, but IBM mainframe assembler. That's way cooler than x86.
Yeah, sounds like a cool project!
Java seems like a good choice for the IRS. There are legions and legions of programmers well versed in Java, since its among the most commonly used programming languages to introduce programming at universities. This means the IRS should be able to focus its hiring on "People who know tax law and can use Java" instead of "Java experts that know enough tax law to be dangerous".
Its not the flashiest language, but I think its the right choice for them.
Its not the flashiest language, but I think its the right choice for them.
What makes you think the developers have to "know tax law"?
It might be a peripheral plus for an applicant, but it's more important they are a competent programmer.
"Tax law" changes constantly - you truly cannot reasonably expect a developer to "know tax law" and be a competent programmer.
It might be a peripheral plus for an applicant, but it's more important they are a competent programmer.
"Tax law" changes constantly - you truly cannot reasonably expect a developer to "know tax law" and be a competent programmer.
"Know tax law" in the context of a software developer I would interpret as understanding the core concepts and terminology involved in tax law, not knowing all the intricacies involved in every single piece of tax law. They need to be able to understand the specific pieces of tax law that they are working on with the help of an actual expert without too much friction; they don't have to be actual experts on tax law.
by "know tax law", I'd assume they mean the same thing as know react - that is, they have experience doing it previously.
Seems unlikely that they can hire many cross functional tax-law-programmers. You integrate teams so there are experts on both.
Maybe, but my line of thinking is that it could be easier and better to teach tax law specialists a little bit of Java, than the other way around
I don’t know how much validation the code does, but every single number in your tax forms is related to another by some statement in the law, and these change constantly. Validating them means codifying every single rule.
Germany figured this out a while ago and built a rule engine with GUI and small DSL where the lawyers can input tax rules to the database - meaning better code and you can emit for any platform. It’s called ElsterRules (Elster is the online tax filing program) and runs even in your browser... I wonder if there’s something similar in other countries.
Germany figured this out a while ago and built a rule engine with GUI and small DSL where the lawyers can input tax rules to the database - meaning better code and you can emit for any platform. It’s called ElsterRules (Elster is the online tax filing program) and runs even in your browser... I wonder if there’s something similar in other countries.
Its not the flashiest language so I think its the right choice for them.
FTFY
FTFY
What this article implies is not entirely correct: this codebase is not S/370 assembly, oh no. It's IBM 7074! Check also the reports which said the Master File age was over 55 years -- the S/370 is too new for that.
https://books.google.ca/books?id=3iEDAAAAMBAJ&pg=PA88&lpg=PA...
https://books.google.ca/books?id=3iEDAAAAMBAJ&pg=PA88&lpg=PA...
There was an interesting article/HN story a year ago about the government working Java into an ancient IBM 7074 system: https://thenewstack.io/happens-use-java-1960-ibm-mainframe/
HN discussion here: https://news.ycombinator.com/item?id=13464675
HN discussion here: https://news.ycombinator.com/item?id=13464675
> Converting assembler code won’t be such a simple input-output matter [as turning a dog into a sausage and back again as shown in the linked b/w film]
Actually this is the best analogy I could possibly imagine.
Actually this is the best analogy I could possibly imagine.
Funny how it's always the same companies producing code for the government based on political relationships - but the outcome of government software is always so bad.
Political relationships aren't the entire problem. You have to be a BigCo with an established relationship with the government to be able to comply with the rules and lobby for a contract that favors you.
If anyone could land a contract just because a senator owed them a favor you'd see a lot more diversity in who the government does business with.
If anyone could land a contract just because a senator owed them a favor you'd see a lot more diversity in who the government does business with.
Does anyone know who is the prime contractor for this particular engagement?
It sounds like the effort might have been a step in the right direction, but hardly a solution in its own right. The result would be a literal case of the aphorism "You can write assembly in any language."
The translation would have some minor benefits: interop with java libraries would be nice, it could help to plug the system into better infrastructure like a modern testing framework, and it might run a little more securely. (I wonder whether you could craft a tax return to crash this system.) But it wouldn't have magically produced readable modern java code.
The translation would have some minor benefits: interop with java libraries would be nice, it could help to plug the system into better infrastructure like a modern testing framework, and it might run a little more securely. (I wonder whether you could craft a tax return to crash this system.) But it wouldn't have magically produced readable modern java code.
If you can separate areas of functionality, you can upgrade it piece-by-piece. So while it starts off as 98% inscrutable assembly-in-Java, you transform it over time until it's only 2%. Ideally, backed with strong tests and fuzzing.
Absolutely, but it's a long way from a solution.
One has to wonder whether it really makes sense to port instead of taking a look at the workflow and simply implement it from scratch.
I maintain a code base written by others and I fight this feeling all the time.
If (re)writing software has taught me anything is that sentences that start with "simply" or "just" actually mean that you don't fully understand the problem.
If (re)writing software has taught me anything is that sentences that start with "simply" or "just" actually mean that you don't fully understand the problem.
To be fair, there's a tendency to fight starting from scratch, on the (arguably incorrect) assumption that starting over introduces higher risk, and greater time & cost.
IMO, all-at-once rewrites are almost never a good option. Ship of Theseus style rewrites where every component eventually gets replaced but there is never a hard dividing line between old product and new product can be a good idea.
"simply implement" may be an understatement, but often enough, rewriting/reimplementing IS simpler (and cleaner, and more maintainable, etc etc etc) than keeping a legacy system going
The best argument to new development is working code. I assume that they can't hire people to upgrade or maintain Maniframe software anymore.
Working code is king, but in the IRS's case it's a very expensive king.
A huge amount of fraud happens by exploiting a timing attack against the batch processing architecture of the existing process. The system only has visibility into data from previous batches, it's blind to what's been done during the the currently processing batch. One exploitable artifact of this is that if you try to claim someone as a dependent (and potentially get child tax credits, EIC, etc) and they've already been claimed in a previous batch, your return will get rightfully rejected. But if multiple returns claim that person in the same batch, and they haven't been claimed in a previous batch, they'll all get accepted. The IRS will catch it after the fact, but by that point they've already paid out the fraudulent returns. If it's something like a misunderstanding between spouses on who claims a kid, it's likely they'll straighten it out and get their money back. If it's outright fraud, then they'll probably be out that money completely (plus investigative costs).
That's just one example, but there are billions of dollars worth of fraud that happens every year which could be prevented by migrating the IRS systems from offline batch processing to an online/real-time transactional architecture.
A huge amount of fraud happens by exploiting a timing attack against the batch processing architecture of the existing process. The system only has visibility into data from previous batches, it's blind to what's been done during the the currently processing batch. One exploitable artifact of this is that if you try to claim someone as a dependent (and potentially get child tax credits, EIC, etc) and they've already been claimed in a previous batch, your return will get rightfully rejected. But if multiple returns claim that person in the same batch, and they haven't been claimed in a previous batch, they'll all get accepted. The IRS will catch it after the fact, but by that point they've already paid out the fraudulent returns. If it's something like a misunderstanding between spouses on who claims a kid, it's likely they'll straighten it out and get their money back. If it's outright fraud, then they'll probably be out that money completely (plus investigative costs).
That's just one example, but there are billions of dollars worth of fraud that happens every year which could be prevented by migrating the IRS systems from offline batch processing to an online/real-time transactional architecture.
Their batch processing is definitely an interesting case, as it how it processes failures (had them as a customer of mine a couple years back where I was working on improving their responses to failed jobs (and accelerating the time between reruns)).
They've got a decent team that manages their mainframe systems
> Wang was working under streamlined critical pay authority the agency has had since its landmark 1998 restructuring. It gave the IRS 40 slots under which it could pay temporary, full-time employees higher than GS rates. Former Commissioner John Koskinen pointed out Congress did not re-up this authority in 2013, despite his entreaties to former Congressman Jason Chaffetz’s Committee on Oversight and Government Reform.
> He says he applied to become a GS-15 or Senior Executive Service member so he could see through the assembler-to-Java project. But his approval didn’t come through until a week before his employment authority expired. By then he’d accepted another job.
(GS-15 is $103k-$134k. https://www.federalpay.org/gs/2017/GS-15)
So, basically: the IRS can't fix its software because it can't pay market rates for software engineers. It can't pay market rates for software engineers not because it lacks the budget for it, but because Congress won't let them. This is how it ends up with huge armies of bureaucrats doing things that could be easily automated.
> He says he applied to become a GS-15 or Senior Executive Service member so he could see through the assembler-to-Java project. But his approval didn’t come through until a week before his employment authority expired. By then he’d accepted another job.
(GS-15 is $103k-$134k. https://www.federalpay.org/gs/2017/GS-15)
So, basically: the IRS can't fix its software because it can't pay market rates for software engineers. It can't pay market rates for software engineers not because it lacks the budget for it, but because Congress won't let them. This is how it ends up with huge armies of bureaucrats doing things that could be easily automated.
The actual federal pay schedules are here: https://www.opm.gov/policy-data-oversight/pay-leave/salaries...
The GS-15 range for the DC area is $135k-164k. For federal government employees, salary only represents about half of their total compensation, which includes a lifetime inflation adjusted pension and medical benefits.
The GS-15 range for the DC area is $135k-164k. For federal government employees, salary only represents about half of their total compensation, which includes a lifetime inflation adjusted pension and medical benefits.
...and any sizable employer offers healthcare and a 401(k). So at best you could say they're betting on an inflation-adjusted pension? That's not going to sell many candidates.
I'm not from the US, but I'm guessing a 401(k) pension scheme is defined contribution: you pay in cash in a tax advantaged way, and the risk that the pension scheme loses money or doesn't make enough of a return to support you in retirement is borne by you.
I'm also guessing that the government's pension scheme is defined benefit: the risk that the scheme loses money is borne by the government, and you get your pre-determined payout unless the government goes bankrupt.
Defined contribution pensions are typically much more valuable, since they can obviate the need to save for retirement (or at least part of that need).
In the UK, it's extremely competitive to become a civil servant despite the mediocre pay. The reason is security, both in your job and in retirement.
I'm also guessing that the government's pension scheme is defined benefit: the risk that the scheme loses money is borne by the government, and you get your pre-determined payout unless the government goes bankrupt.
Defined contribution pensions are typically much more valuable, since they can obviate the need to save for retirement (or at least part of that need).
In the UK, it's extremely competitive to become a civil servant despite the mediocre pay. The reason is security, both in your job and in retirement.
Yes that's right, but you've got the terms reversed. Defined contribution is the one where you bear the risk, and defined benefit is where the government bears the risk.
A portion of the risk. PBGC pays out at a significant discount.
Whoops! My bad - edited.
I would take a government guaranteed pension and lifetime health care over 401k any day.
They are only guaranteed until some elected official decides to give you a haircut on your deferred paychecks (Which is what a pension is), right as you're about to retire. (Or shortly after you do.)
I'd hedge, and prefer splitting my money between both.
I'd hedge, and prefer splitting my money between both.
Attempting such a cut would result in a protracted legal battle with some of the most powerful organizations in the country.
Unions? Government employees? They aren't even on the top ten of 'most powerful organizations in the country.' Not for the past four decades - Ronald Reagan fixed that glitch.
What's going to happen is that paid shills will start publishing op-eds citing a handfull of executives and upper managers who gamed the pension payments system with overtime, resulting in massive payouts for themselves, drum up public outrage about lazy government workers, and pass an across-the-board haircut. It will, as always, be turned into a red vs blue issue - and half the time, red's in charge.
What's going to happen is that paid shills will start publishing op-eds citing a handfull of executives and upper managers who gamed the pension payments system with overtime, resulting in massive payouts for themselves, drum up public outrage about lazy government workers, and pass an across-the-board haircut. It will, as always, be turned into a red vs blue issue - and half the time, red's in charge.
I don't believe they will ever touch federal government pensions. Municipal maybe, but not federal.
You still can do both if you work for the government.
But you exchange a lower salary for that government job, which makes saving for your 401k & co less effective. There is also the entire calculation of the expected value of money now vs 30 years from now.
Govt salaries aren’t that low.
The inflation adjusted pension, which roughly works out to 33% of your final salary, is in addition to the federal 401k program and social security.
The fact that it is inflation adjusted is critical. To calculate the value of the pension plan, you would need to compute the NPV of an infinite series (assuming advancing healthcare).
The medical benefits are also quite significant and, for lower grade workers, will dwarf the value of the pension.
The fact that it is inflation adjusted is critical. To calculate the value of the pension plan, you would need to compute the NPV of an infinite series (assuming advancing healthcare).
The medical benefits are also quite significant and, for lower grade workers, will dwarf the value of the pension.
Government employees tend to be highly risk averse. This was the insight behind the founding of GEICO, the Government Employees Insurance Company, which used to write policies for public employees only.
The tax benefits of being an IRS programmer who writes critical code that nobody else can understand are incalculable.
I see what you did there...
> For federal government employees, salary only represents about half of their total compensation, which includes a lifetime inflation adjusted pension and medical benefits.
A relative of mine has been a federal employee for over a decade and gets neither of those. She has a TSP (like a government 401k) and that's it.
Maybe some federal employees got something like this at some point, but it's very misleading to just drop that into conversation like it's true across the board.
A relative of mine has been a federal employee for over a decade and gets neither of those. She has a TSP (like a government 401k) and that's it.
Maybe some federal employees got something like this at some point, but it's very misleading to just drop that into conversation like it's true across the board.
Your relative either doesn't have an understanding of her retirement plan or isn't telling you everything. One component of the FERS is the "Basic Benefit Plan" which is the pension.
https://www.investopedia.com/articles/personal-finance/06251...
https://www.investopedia.com/articles/personal-finance/06251...
I followed up on this and you're right, there is a pension component too. Although she laughed and said it is "hilariously small."
> For federal government employees, salary only represents about half of their total compensation, which includes a lifetime inflation adjusted pension and medical benefits.
No, nowadays you have to pay in for retirement and medical benefits. Retirement money is partially matched, but health care generally is no cheaper than a good private plan.
No, nowadays you have to pay in for retirement and medical benefits. Retirement money is partially matched, but health care generally is no cheaper than a good private plan.
What kind of medical benefits are we talking about? How many years do you have to work for the government to get it?
My employer's healthcare plan costs my employer ~20k/year as long as I'm employed, more if I had children, yet for some reason, nobody ever counts that as part of AMAFAGOPL salaries.
My employer's healthcare plan costs my employer ~20k/year as long as I'm employed, more if I had children, yet for some reason, nobody ever counts that as part of AMAFAGOPL salaries.
I wasn't sure if "AMAFAGOPL" was a real acronym or just something you made up, so I searched for it on Google. The only result was a link to your comment - posted just 12 minutes ago. Google is getting (scary) good at indexing social content, it seems.
There's several tiers of indexing in Google Search (it's a pyramid, with Instant near the top when that existed), and lots of social stuff is refreshed very frequently at the top of it. That is how recent Tweets show up in searches, as well.
I'd be curious how often Googlebot hits HN.
I'd be curious how often Googlebot hits HN.
Amazon-microsoft-facebook-google-apple.
There's not a single "federal employee medical plan", there's a set of insurance plan choices like most large employers and you choose what level of risk/deductible and coverage you want for what you're willing to pay. Standard Flex Savings and Health Savings plans are also available. AFAIK you're eligible to sign up on day one of employment just like most employers. My wife is a fed, last year the government contributed $14k to our health insurance, which is pretty much in line with most plans from large companies. I've had developer jobs where the benefit plans were competitive or comparable to our federal benefits plan, we just stay on the federal plan because my wife doesn't plan on leaving federal service and the continuity is easier. The only advantage really is that there's a lot of federal employees on every possible plan so all the plans are pretty good compared to what you can get at smaller companies. If you work at a company of a 100 or more people, that company should be able to get you similar rates. I don't have first hand experience or much knowledge to speak to, but I have heard federal insurance plans are quite desirable for folks with expensive pre-existing conditions.
The other reply is a bit dated too, there's no longer a real pension available to new employees. There are probably still long-term employees or retirees kicking around with those older pre-1987 retirement packages, but all recent hires are on a plan that's pretty much equivalent to a 401k (Thrift Savings Plan) + a Basic Benefits plan (which is pretty basic and you still pay into. It roughly equates to getting two Social Security payments instead of one). The bulk of a federal employee's retirement funds will come from contributions to their TSP plan.
The other reply is a bit dated too, there's no longer a real pension available to new employees. There are probably still long-term employees or retirees kicking around with those older pre-1987 retirement packages, but all recent hires are on a plan that's pretty much equivalent to a 401k (Thrift Savings Plan) + a Basic Benefits plan (which is pretty basic and you still pay into. It roughly equates to getting two Social Security payments instead of one). The bulk of a federal employee's retirement funds will come from contributions to their TSP plan.
So, your medical plan evaporates the moment you stop working for most federal agencies? Just like my private employer's medical plan?
And guaranteed pensions are no longer a thing? What is left as a justification for below-market salaries? Employment opportunities in government-dominated towns (which do not have healthy private-sector economies), and more job security?
And guaranteed pensions are no longer a thing? What is left as a justification for below-market salaries? Employment opportunities in government-dominated towns (which do not have healthy private-sector economies), and more job security?
> So, your medical plan evaporates the moment you stop working for most federal agencies? Just like my private employer's medical plan?
Yes.
>And guaranteed pensions are no longer a thing?
They pitch it as a three legged stool: social security, your 401k, and then a pension that pays out according to a formula (the amount you get in a year is calculated somewhat like pension := (1% of the average salary of the three highest paid contiguous years of service) * number of years of service, up to 20 (after 20 years the percentage goes down). Between the three legs of the stool you can probably get to about 60% of your income, which is supposed to be reasonable for retirement.
> What is left as a justification for below-market salaries? Employment opportunities in government-dominated towns (which do not have healthy private-sector economies), and more job security?
The salary isn't at all bad. For some specialties it's below market, but for the average joe it's pretty decent. But it's worth noting that, for me, the job security is key. I've made more money contracting, but contracts end, sometimes abruptly, and the peace of mind you get from having security is very valuable.
Yes.
>And guaranteed pensions are no longer a thing?
They pitch it as a three legged stool: social security, your 401k, and then a pension that pays out according to a formula (the amount you get in a year is calculated somewhat like pension := (1% of the average salary of the three highest paid contiguous years of service) * number of years of service, up to 20 (after 20 years the percentage goes down). Between the three legs of the stool you can probably get to about 60% of your income, which is supposed to be reasonable for retirement.
> What is left as a justification for below-market salaries? Employment opportunities in government-dominated towns (which do not have healthy private-sector economies), and more job security?
The salary isn't at all bad. For some specialties it's below market, but for the average joe it's pretty decent. But it's worth noting that, for me, the job security is key. I've made more money contracting, but contracts end, sometimes abruptly, and the peace of mind you get from having security is very valuable.
Yeah, basically. If your federal employment ends your medical benefits do as well. It's not like a professor's tenure or anything. But unlike the private sector, if you served for at least 5 years you can re-enroll after you reach retirement age and the government will pick up the "employer's costs" of your insurance once again. You'd still be paying the premiums out of pocket though (which is better than other jobs or Medicare if you can afford it).
There is still a small guaranteed basic pension that federal employees pay into, but it's not really enough to retire on by itself. It's one part of their 3 part retirement plan. Couple it with Social Security (the second part) and you could probably scrape by and remain reasonably well fed and housed if you relocated somewhere rural and cheap, but if you plan on retiring and staying put you're going to have to save using the TSP (the third part) like anyone else saves with a 401k.
I can't provide a blanket statement for why people are federal employees though, it's probably different in each industry. My wife is part of the scientific and regulatory side of the oil and gas industry and [benefits included] she doesn't earn substantially less than her private industry peers in similar scientific roles. And that industry is notorious for frequent and cut throat boom-bust cycles which brings it even closer to parity over the long haul. As a software developer though, not a chance. The desirability of the roles they have and the compensation even with benefits is not usually very attractive and the federal hiring process is bonkers compared to most companies.
There is still a small guaranteed basic pension that federal employees pay into, but it's not really enough to retire on by itself. It's one part of their 3 part retirement plan. Couple it with Social Security (the second part) and you could probably scrape by and remain reasonably well fed and housed if you relocated somewhere rural and cheap, but if you plan on retiring and staying put you're going to have to save using the TSP (the third part) like anyone else saves with a 401k.
I can't provide a blanket statement for why people are federal employees though, it's probably different in each industry. My wife is part of the scientific and regulatory side of the oil and gas industry and [benefits included] she doesn't earn substantially less than her private industry peers in similar scientific roles. And that industry is notorious for frequent and cut throat boom-bust cycles which brings it even closer to parity over the long haul. As a software developer though, not a chance. The desirability of the roles they have and the compensation even with benefits is not usually very attractive and the federal hiring process is bonkers compared to most companies.
The justification for below-market salaries is that you aren't expected to actually produce anything and are almost impossible to terminate unless you commit fraud or harassment. This comes from first hand experience as a federal engineer for almost a decade.
My mother-in-law's first hand experience in handling medical treatment cases for VA for the past decade is that you're expected to handle more cases then you have the time to.
You're also expected to do so, while wading through a waist-deep morass of technological, beurocratic, and managerial stupidity.
In that agency, she can't just zone out and phone it in.
You're also expected to do so, while wading through a waist-deep morass of technological, beurocratic, and managerial stupidity.
In that agency, she can't just zone out and phone it in.
[deleted]
[deleted]
> This is how it ends up with huge armies of bureaucrats doing things that could be easily automated.
Less bureaucracy and lower costs sounds like something anyone would agree on, but remember that a large part of congress has run on anti-tax promises. Hampering the efficiency of the IRS is one way of making good on that.
Less bureaucracy and lower costs sounds like something anyone would agree on, but remember that a large part of congress has run on anti-tax promises. Hampering the efficiency of the IRS is one way of making good on that.
There's also the tax prep lobby, which is opposed to more automation, streamlining of code, and making tax prep irrelevant in general. Half the IRS could go away if most americans could do a simple 1040 on an IRS website.
Eg: http://billmoyers.com/story/how-lobbying-by-tax-preparer-hel...
Eg: http://billmoyers.com/story/how-lobbying-by-tax-preparer-hel...
[deleted]
This is not a partisan issue. Both parties have a long history of meddling with the IRS and generally making things worse.
No, you can't say it's bipartisan when Republicans have consistently sought to intentionally damage the IRS by underfunding it. They even tried to impeach the IRS chief because he wouldn't go along with their manufactured fake news scandal about the Tea Party.
Republicans like Obama who reduced funding for the IRS multiple times while in office?
Odd that I remember him pushing to increase their budget then: http://www.govexec.com/management/2016/02/obama-would-hike-i...
In general, it does seem true that Republicans haven't been interested in funding the IRS, even though they seem to believe testimony that more funding would increase government income.
In general, it does seem true that Republicans haven't been interested in funding the IRS, even though they seem to believe testimony that more funding would increase government income.
Did he reduce it, or was it simply reduced while he was in office. Because he had a Republican Congress for 75% of his presidency.
Obama had a republican Congress since 2010, which is when the IRS cuts started.
I work for a state government agency with a big software problem that has a hard time hiring for this reason. We've got some talented devs only due to the fact that they enjoy living in the area, not because they enjoy getting half(or less!) what they'd make in the private sector.
I would work for the government (I did, a couple times) on projects I think will benefit my fellow citizens. This tax reform is not like that.
Converting Assembly to Java isn't "tax reform" and nobody is going to pat you on the back for making an economically disadvantageous decision just because you believe it benefits your fellow citizens. If you want warm fuzzies and to get paid then look at contracting. That's how we fill the gaps when we get literally 0 applicants because the FTE rate for our dev positions is laughably low.
Public sector employers need to compete in the same job market as private sector employers. I can only speak about my department but we're hamstrung by bureaucratic and legislative inertia that is completely out of our control. I believe the mission of my department is an important one but if the private sector software market was more robust in my city and pay scales were just as disproportionate as they are now I would choose a private sector job 10 out of 10 times. The only ones here not constantly checking LinkedIn are the lifers that already have a fat pension and are reasonably close to retirement.
Public sector employers need to compete in the same job market as private sector employers. I can only speak about my department but we're hamstrung by bureaucratic and legislative inertia that is completely out of our control. I believe the mission of my department is an important one but if the private sector software market was more robust in my city and pay scales were just as disproportionate as they are now I would choose a private sector job 10 out of 10 times. The only ones here not constantly checking LinkedIn are the lifers that already have a fat pension and are reasonably close to retirement.
$103k-$134k sounds very market rate to me... Maybe not for the San Francisco Bay Area but for areas outside of that it seems fine.
The IRS is based in D.C., which also has a high COL. Additionally, that's for the GS-15 paygrade, which requires a PhD and is the highest possible level -- so you can't be paid more than that. The corresponding paygrade for someone with a masters, or with a few years of experience, is $43-$56k[0]. It's definitely below market IMO.
[0] https://www.federalpay.org/gs/2017/GS-9
[0] https://www.federalpay.org/gs/2017/GS-9
Who says the place of performance has to be DC?
As a developer in that area, its not super competitive. It is not even close to what a good senior dev is making. They also don't hire people at this level often because you are talking about a director level position. There is huge political push back. This is why its common for the contractors on the project to be paid twice as much as the employees.
Yeah, as a developer in the area with under 5 years of professional experience I am already at the top end of that range. I did no job hopping, do not work for a company that is particularly well known for high pay and did not graduate from a school with a very well known CS program. I have also heard from former co-workers with similar levels of experience who have moved on to other companies that they are making similar amounts.
It is above average for the area (across all levels of experience, for a very experienced developer it probably isn't), but it is not very far above average, so I would expect someone capable of handling such a massive and critical project to be making significantly more.
It is above average for the area (across all levels of experience, for a very experienced developer it probably isn't), but it is not very far above average, so I would expect someone capable of handling such a massive and critical project to be making significantly more.
GS-15 is the top of the pay scale though, there's no such thing as a GS-16 just step increases that come with years of employment.
Plus, would you really want to endure the months of their hiring process (which intentionally filters out people not wanting a long term job) just to join an agency that has no promotion potential for you over the long term?
Plus, would you really want to endure the months of their hiring process (which intentionally filters out people not wanting a long term job) just to join an agency that has no promotion potential for you over the long term?
[deleted]
Not if you want a good senior developer. These guys are perpetually stuck with junior devs.
Compensation is a vector, not a scalar.
GS employees almost cannot be fired, government-employee unions protect their members from not the private sector but from the government, they get better than ACA health care, and their retirement is guaranteed by an entity that can print all the money it wants.
GS employees almost cannot be fired, government-employee unions protect their members from not the private sector but from the government, they get better than ACA health care, and their retirement is guaranteed by an entity that can print all the money it wants.
"1998 restructuring. It gave the IRS 40 slots ... Congress did not re-up this authority in 2013"
That's 15 years of "streamlined critical pay" authority. And it appears that some number of these slots continued to exist until recently. Two decades of special authority to modernize this software, and nothing to show for it, except perhaps some patents...
At some point you have to cut your loses.
That's 15 years of "streamlined critical pay" authority. And it appears that some number of these slots continued to exist until recently. Two decades of special authority to modernize this software, and nothing to show for it, except perhaps some patents...
At some point you have to cut your loses.
Nowhere it says that these slots were created to modernize software. These 40 slots are total amount of people (out of 80K employees) that could be paid above government rates.
These slots were used to fill 168 positions over the 15 years.[1]
[1] https://www.treasury.gov/tigta/press/press_tigta-2014-51.htm
These slots were used to fill 168 positions over the 15 years.[1]
[1] https://www.treasury.gov/tigta/press/press_tigta-2014-51.htm
"armies of bureaucrats doing things that could easily be automates" = "jobs for people who you owe favors but don't want to put in a position where they might screw up something important"
Elected officials have little incentive to make governing any more efficient.
Bureaucrats themselves have some incentive to be more efficient because then they can spend more of their budget at their discretion.
Elected officials have little incentive to make governing any more efficient.
Bureaucrats themselves have some incentive to be more efficient because then they can spend more of their budget at their discretion.
Offer contracts for $130k + Green Card after one year.
You'll get some of the best candidates from India and China lining up.
I work at Amazon in Seattle right now, but I'd take the pay cut to jump the India green card line. Probably go back to Amazon right after I got the green card tho.
You'll get some of the best candidates from India and China lining up.
I work at Amazon in Seattle right now, but I'd take the pay cut to jump the India green card line. Probably go back to Amazon right after I got the green card tho.
I’m sorry but this seems like a fool’s errand. Perhaps Jian Wang is a genius that figured out a way to map IBM 360 assembly to Java that would map to the JVM. Maybe he’s brilliant or maybe his efforts are overhyped by this news piece. It seems that a direct mapping from 360 to the JVM might have made more sense. I suggest that you go look at Rick Hickey’s Clojure code to see how that might look.
Government IT is rife with corruption and incompetence. I have worked for a number of agencies and worked in federal government for many years. Projects are often steered in the direction of contractors and federal employees that benefit from technologies. This is often done to bias incumbent legacy stakeholders and technologies that benefit the federal employees and the contractors that collude to control the systems for their own gains. I have seen the sleaziest contractors enrich themselves at SV IPO levels.
Then came 18F, the hipster government IT revolution. As a senior developer, and maybe I am just some cranky old developer, but the thought of being vetted by this douchebag, fuckin blows my mind: https://18f.gsa.gov/2015/04/08/day-in-the-life-of-talent-man...
Yep, most government and corporate IT is fucked.
Government IT is rife with corruption and incompetence. I have worked for a number of agencies and worked in federal government for many years. Projects are often steered in the direction of contractors and federal employees that benefit from technologies. This is often done to bias incumbent legacy stakeholders and technologies that benefit the federal employees and the contractors that collude to control the systems for their own gains. I have seen the sleaziest contractors enrich themselves at SV IPO levels.
Then came 18F, the hipster government IT revolution. As a senior developer, and maybe I am just some cranky old developer, but the thought of being vetted by this douchebag, fuckin blows my mind: https://18f.gsa.gov/2015/04/08/day-in-the-life-of-talent-man...
Yep, most government and corporate IT is fucked.
Well, I guess once the system is rewritten, we will not get our refunds until 3 years later.
I wonder if I get 2x by expected refund the IRS can come at me to claim the extra amount :)
I wonder if I get 2x by expected refund the IRS can come at me to claim the extra amount :)
Wow, that joke would have been hilarious back in 2000.
Just imagine if this new system was converted to groovy or scala. That would be pretty amazing.
Are people writing new non-Jenkins Groovy code in 2018? What's the use case? Legitimately curious. My experience with Groovy is always frustration and I liken it to the Coffeescript of Java.
Gradle plugins? I wouldn't choose it over Java full time but it has some niceties like multi-line strings to help with testing.
Those can be written in Kotlin now.
You can write the plugins themselves in Java, and so i assume in any JVM language. Having written a few, i prefer Java to Groovy, as the Gradle API (SPI?) is pretty complicated, and it's reassuring to have my use of it typechecked.
It's Gradle build scripts themselves that can now be written in Kotlin instead of Groovy. I haven't tried that yet, but it sounds pretty fresh.
It's Gradle build scripts themselves that can now be written in Kotlin instead of Groovy. I haven't tried that yet, but it sounds pretty fresh.
Grails, POCs, Ratpat (ok danveloper.. we get it, that exists), Spock tests
Why do you regularly get frustrated with groovy?
Why do you regularly get frustrated with groovy?
It's probably a function of it being the language that exists, and my unfamiliarity with it. I regularly just want to do the Java versions of the operation but find myself "translating" to the Groovy code where I'm unfamiliar with the design methodologies of the language and where they differ from the Java methodologies. There's interop, I'm aware, but in things like Jenkins plugins, that's kind of heavy.
If you don't mind me expoliating your situation. It's probably the issue because it's not fundimentally that much different than java. [It's more of a half step] Take some time, read Groovy in Action in depth. Get some experience with it. It can be a lot of fun when you have more experience. (As is the case with scala as well. but that's more of a full step in languages)
[deleted]
> Assembler is like Shakespearean English. It’s dated. A shrinking number of people can deal with it. But it’s also elegant and highly functional.
What is considered elegant and functional about assembly?
What is considered elegant and functional about assembly?
An age ago, I wrote a fast interrupt handler in assembler that was, under its somewhat severe operating constraints, "elegant and functional." That was about a page of code, commented in two-column format, a sort of side-by-side tutorial. There were more lines of comments than lines of code.
Even with that, the junior engineers (familiar with assembly!) were completely flummoxed by it. Domain knowledge encoded in assembly rapidly becomes highly obfuscated, even when written in a literate programming style.
I simply cannot imagine calling large-scale enterprise business logic written in assembly "elegant and functional" for any reason. Even the best written, best documented assembly obfuscates so much meaning .
Even with that, the junior engineers (familiar with assembly!) were completely flummoxed by it. Domain knowledge encoded in assembly rapidly becomes highly obfuscated, even when written in a literate programming style.
I simply cannot imagine calling large-scale enterprise business logic written in assembly "elegant and functional" for any reason. Even the best written, best documented assembly obfuscates so much meaning .
The Shakespeare analogy is perhaps more apt than the writer imagined. A popular version of Shakespeare’s plays have the original text on the left hand pages and commentary and definitions on the right. This is what I imagined what your interrupt handler looked like.
> Tao of Programming 8.3
> There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?"
> The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am."
> The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
And I have heard cool things about mainframe assembly programs (at least on z/TPF). Like a system to do code upgrades without hardly any downtime by pausing the VM, doing brain surgery on it, then resuming it.
> There was once a programmer who wrote software for personal computers. "Look at how well off I am here," he said to a mainframe programmer who came to visit. "I have my own operating system and file storage device. I do not have to share my resources with anyone. The software is self-consistent and easy-to-use. Why do you not quit your present job and join me here?"
> The mainframe programmer then began to describe his system to his friend, saying, "The mainframe sits like an ancient Sage meditating in the midst of the Data Center. Its disk drives lie end-to- end like a great ocean of machinery. The software is as multifaceted as a diamond, and as convoluted as a primeval jungle. The programs, each unique, move through the system like a swift-flowing river. That is why I am happy where I am."
> The personal computer programmer, upon hearing this, fell silent. But the two programmers remained friends until the end of their days.
And I have heard cool things about mainframe assembly programs (at least on z/TPF). Like a system to do code upgrades without hardly any downtime by pausing the VM, doing brain surgery on it, then resuming it.
> Assembler is like Shakespearean English.
Author has no idea what assembler is.
Author has no idea what assembler is.
Yeah, it's more like the individual phonemes that make up each word of every statement.
That, or instructions for controlling tongue positions and vocal chords.
Ah, but with how English has shifted over the centuries, the necessary domain knowledge has slowly been disappearing. Shakespeare's plays now and then [0] are slightly different (and back then, dirtier) because of it. (Jump to 2:30 for an explanation and example, then at 7:58 is the dirty pun that doesn't exist in modern pronunciation.)
[0] https://www.youtube.com/watch?v=gPlpphT7n9s
[0] https://www.youtube.com/watch?v=gPlpphT7n9s
Eh, I feel like this is a pretty apt comparison.
I think the comparison is quite apt. Shakespearean English is an ancestor of today's English, much like assembly languages are the ancestors of today's languages. Shakespearean English is grammatically correct, much like this assembly code is, presumably, correct in doing what it needs to do. And, most pertinent, almost nobody speaks in Shakespearean English, and fewer and fewer people are comfortable working with it, much like assembly language.
I don't think it addresses one of the most important aspect of assembly, though, which is it's strict, functional/feature inferiority to modern languages.
It isn't just old and forgotten, its very style and function is extremely limited in comparison. Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said about assembly.
It isn't just old and forgotten, its very style and function is extremely limited in comparison. Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said about assembly.
"I don't think it addresses one of the most important aspect of assembly, though, which is it's strict, functional/feature inferiority to modern languages."
I think that's addressed in the, "No one really uses it anymore" part.
"Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said about assembly."
I would disagree. Arguably, the main function, if not the only function of English, or any other human language, is to express ideas. Shakespearean English being not commonly used, and many of the colloquialisms and terms used not being in use anymore would make that function more difficult. As an example, I'd use the "Romeo, Romeo, wherefore art thou Romeo?" line. To most people, that would be Juliet asking where Romeo was, but it's not. It's her asking why Romeo had to be who he was, which was a Montague, the rival/enemy of her family.
I think that's addressed in the, "No one really uses it anymore" part.
"Shakespearean English is just about as functional of a language as modern English (ignoring the vocabulary for things that didn't exist back then), which can't be said about assembly."
I would disagree. Arguably, the main function, if not the only function of English, or any other human language, is to express ideas. Shakespearean English being not commonly used, and many of the colloquialisms and terms used not being in use anymore would make that function more difficult. As an example, I'd use the "Romeo, Romeo, wherefore art thou Romeo?" line. To most people, that would be Juliet asking where Romeo was, but it's not. It's her asking why Romeo had to be who he was, which was a Montague, the rival/enemy of her family.
Not the exact description I would give assembler. However, I would agree that it can be very elegant and efficient.
Although, not all assembly code is like that. Further, you depend on the device it written for to still be around.
However, I don't see a problem with assembly so that fact they are just converting to just convert it. Seems a bit frivolous. If they are having trouble hiring assembler programmers that's kinda a different issue.
However, one nice thing is that any can program in assembler and well tend be good programmers. They know what they are doing. So by switching languages they open themselves up to worse programmers.
However, Java why? If they are coding in assembly wouldn't C make more sense?
Although, not all assembly code is like that. Further, you depend on the device it written for to still be around.
However, I don't see a problem with assembly so that fact they are just converting to just convert it. Seems a bit frivolous. If they are having trouble hiring assembler programmers that's kinda a different issue.
However, one nice thing is that any can program in assembler and well tend be good programmers. They know what they are doing. So by switching languages they open themselves up to worse programmers.
However, Java why? If they are coding in assembly wouldn't C make more sense?
I actually liked programming IBM/370 assembler. It wasn't half bad once you got past EBCDIC. It was certainly better than the x86. It also was pretty much eternal.
I think I still have my banana book somewhere. https://i.pinimg.com/originals/fb/85/89/fb85890d32df071cf842... http://cbttape.org/~jmorrison/s370asm/html/tut-REFSUM-001.ht...
I think I still have my banana book somewhere. https://i.pinimg.com/originals/fb/85/89/fb85890d32df071cf842... http://cbttape.org/~jmorrison/s370asm/html/tut-REFSUM-001.ht...
This is not just S/370 assembler, the real ancient parts are IBM 7074. See for example https://books.google.ca/books?id=3iEDAAAAMBAJ&pg=PA88&lpg=PA... but I read some protocol docs that some of the data is still encoded as it was in the 7074.
I've always thought the formatting kind of lends itself to a little bit of visual elegance. Since its always 1 instruction per line, various instruction fields tend to line up nicely.
But yeah I don't see how it is elegant in any way that's useful
But yeah I don't see how it is elegant in any way that's useful
Although it may appear a bit surprising at first, assembly language is homoiconic in the sense that you can easily reason about the program code within the language: It is easy to reason about bytes in assembler language, and compiled assembler code is just a sequence of bytes.
This is similar to high-level languages like Lisp and Prolog, whose code is readily represented by built-in data structures in the respective language.
A fun fact about this is that extremely low-level (like assembly) and extremely high-level (like Prolog) languages are homoiconic, but there is a large gap "in the middle" (like Java, C), where there are many languages that lack this property.
This is similar to high-level languages like Lisp and Prolog, whose code is readily represented by built-in data structures in the respective language.
A fun fact about this is that extremely low-level (like assembly) and extremely high-level (like Prolog) languages are homoiconic, but there is a large gap "in the middle" (like Java, C), where there are many languages that lack this property.
6502 assembly is one of the sharpest smoothest most beautiful assembly languages, because all the opcodes are three letters long, so it doesn't have a jagged serrated right edge like most other assembly languages. Much less friction!
For that matter, I take issue with the idea that Shakespearean English is any more elegant or functional than contemporary English. I would consider the poorly standardized spelling and, to an extent, grammar, to be pretty damn inelegant!
It's about as elegant as a mechanical watch is versus an electronic one, it has a ton of moving parts and it is a tricky thing to maintain. It's functional in that it gets the job done, I highly doubt they meant functional in the functional programming sense of the word.
The more I study functional programming the more I see a mapping between structures (reduce/fold,...) and assembly. Assembly requires you to be very very careful, but if you're used to that you can encode these patterns in short ways. But it's a lost art nowadays.
That's opposed to the view often put forward by FP advocates. Tell us more.
Old cpus had a simpler arch (68000 ancestor or something like that), often with two registers A,B serving as accumulator,next pair for reduce/fold like processes. To me it's clearly a reflection of mathematical structures, which are also the root of FP.
With time register sets grew, ISA grew, this got muddied by usage.
With time register sets grew, ISA grew, this got muddied by usage.
If you machine translate assembler to Java won't you still end up with confusing code?
Yes, very much so.
In addition, some of the automated translators I have seen also apply automated refactoring: They tend to merge similar sections of code and minimize the delta (similar to diff) that is factored out. This can create a maintenance problem especially in the context of a system like the IRS's, where presumably the code that performs calculations for different years or other periods (legislations etc.) is similar but not identical, but must be retained as fully as possible to reliably perform calculations that are subject to earlier regulations.
Such portions of code should be kept distinct, but an automated conversion may conflate them, and it may require additional and error-prone fiddling to enforce the separation.
In addition, some of the automated translators I have seen also apply automated refactoring: They tend to merge similar sections of code and minimize the delta (similar to diff) that is factored out. This can create a maintenance problem especially in the context of a system like the IRS's, where presumably the code that performs calculations for different years or other periods (legislations etc.) is similar but not identical, but must be retained as fully as possible to reliably perform calculations that are subject to earlier regulations.
Such portions of code should be kept distinct, but an automated conversion may conflate them, and it may require additional and error-prone fiddling to enforce the separation.
> in theory, there’s no way to translate assembler code. They way it runs is not how it reads
Wat?
Wat?
If you do crazy "tricks" to get the space down like self modifying code or jumping into data then it won't run how it reads. It's a lot easier to do this in assembly because data and code aren't distinct.
On the other hands, there are some "tricks" that someone trying to duplicate that functionality in a higher level language can do, too.
For example, our computers nowadays are much faster and have much more memory. So suppose you have some long, tricky section of assembly code that you know computers some sort of function of a single 32-bit input.
You could simply run that section, in a simulator, with all possible 32-bit inputs and make a table of the results. Then instead of trying to understand what is going on by following the convoluted assembly, your task is to implement the function given by that table. With the function in table form you can do things like look for sections that are linear, or constant, of follow other common patterns.
Hopefully you can get some idea from context in the assembly code what, at a high level, the function is doing, and that should further help you see patterns in the table.
For example, our computers nowadays are much faster and have much more memory. So suppose you have some long, tricky section of assembly code that you know computers some sort of function of a single 32-bit input.
You could simply run that section, in a simulator, with all possible 32-bit inputs and make a table of the results. Then instead of trying to understand what is going on by following the convoluted assembly, your task is to implement the function given by that table. With the function in table form you can do things like look for sections that are linear, or constant, of follow other common patterns.
Hopefully you can get some idea from context in the assembly code what, at a high level, the function is doing, and that should further help you see patterns in the table.
At that point you might as well embed an emulator with a facility to call to/from plain java code. Then you could gradually move things over as needed.
s360 has a lot of cool features for self modifying code like the 'ex' instruction. That tends to point out exactly what's happening when you read it.
https://en.wikibooks.org/wiki/360_Assembly/360_Instructions/...
https://en.wikibooks.org/wiki/360_Assembly/360_Instructions/...
Oh wow the article says that. "It does not run how it reads really..." that is the polar opposite of assembly.
Compiled languages are more likely do thing under the head you don't expect especially a language ran in VM with garbage collection like Java.
Also Java why? I would not trust a language system dependent oracle. The days of Sun Microsystems is sadly gone. =(
Compiled languages are more likely do thing under the head you don't expect especially a language ran in VM with garbage collection like Java.
Also Java why? I would not trust a language system dependent oracle. The days of Sun Microsystems is sadly gone. =(
jhayward elsewhere in these comments explains what they might mean: https://news.ycombinator.com/item?id=16378486
I actually thought that sounds like an elegant starting premise (on the part of Jian Wang). That is, instead of starting with the assumption that you can translate it, start with the assumption that you can't (directly) translate it (and ask, "well then what can you do?") I believe a consequence of Rice's Theorem is that the quoted statement is more or less correct. However the technique of translating it to a simpler intermediate language, and moreover factoring out data as an explicit and separate stream, changes an intractable problem into a not-quite-intractable one. I'm pretty sure I've seen a pure-theory computer science paper, recently, which applies a similar technique on a completely different problem, but I can't remember where I saw it.
I'll just leave this here: https://www.cs.utah.edu/~elb/folklore/mel.html
It's quite simple actually: just make very long names for everything, instead of very short ones.
> assembler
> elegant
> functional
Good one, mate
> elegant
> functional
Good one, mate
Or rewrite it in LLVM.
[deleted]
dethswatch(3)
Java? Hope they don't need an unsigned byte.
I feel like if the IRS had a software provider that was privatized, this would not be an issue.
I've always thought that this type of government work should be open to bids from anyone. If the government is worried about trojans, malware, etc., then they can easily hire an auditor to audit the code and vouch for its authenticity. The fact that only very large, well-connected corporations get a crack at these types of problems is insane and a complete waste of taxpayer money.