Wow, what a cool project to work on: working out the logic flows in assembler and breaking them out so that they can be translated into a higher-level language.
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.
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.
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.
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.
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).
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
> 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.
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...]
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.
> 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.
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.
"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.
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.
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.
> 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.
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.
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.
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.
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.
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
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.
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)).
> 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.
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 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
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?
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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?
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...
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]
"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.
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.
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...
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.
We use it for an embedded DSL to describe business logic quite successfully. Easily extendable via categories and embeds naturally in a larger JVM application.
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 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)
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 .
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.
> 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.
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.)
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.
"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.
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?
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'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
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.
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.
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.
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.
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.
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.
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'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.