> 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...

> [Wang] 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.

They lost a guy responsible for software that could save taxpayers how much -- tens of millions of dollars? More? All because they couldn't pay a guy a GS-15 salary, which translates to $100k-140k.

Man, people are really dumb about paying programmers well. They'd rather see a project go off the rails than pay someone (still slightly below) market rates.

Also:

> In many ways, assembler is still excellent for this application. Milholland said of the code, “The assembler is well written. It’s incredibly efficient and effective.” But a shrinking number of people understand it. And it’s not optimized for the online, transaction mode to which the IRS needs to keep moving. Java, relatively inefficient as it may be, is the current standard and has legions of people who know it.

That's like arguing mixing concrete by hand is "more efficient" because doing so allows you to be more frugal with concrete.

> That's like arguing mixing concrete by hand is "more efficient" because doing so allows you to be more frugal with concrete.

No, that's more like saying mixing concert by hand starts to become attractive because there's only one guy on Earth who knows how to operate a cement mixer. The alternative is crap, but it's easy to find people to do it.

Honest question: do you really think we'd be better off using assembly for run-of-the-mill business logic applications, if there was a workforce that was well trained on it?

Assembly in itself is probably too low-level and doesn't have enough abstractions to be able to develop and maintain a typical business application, but the language itself isn't really the reason. What made companies switch to the cool kids that were Java, Python and Javascript is that the time it takes to learn these languages enough to be productive as a grunt developer is low. It's not so much about the workforce already being well trained or not (there definitely are experts in COBOL and other ancient languages), it's that getting new people up to speed is easy. They will mostly spend their time on the actual business logic instead of stumbling on syntax errors.

This is the reason that makes me believe Go is going to be the new Java: a language with good enough performance, lots of safeguards preventing sloppiness to break, and a very very flat learning curve.