Hacker News Reader

Comment by wins32767 | Hacker News Reader

The part that was shocking to me but shouldn't have been was the rationale for not using what sounds like a transpiler from Kennedy era Assembly to Java:

> White added, “The Java that was created by the automatic tool [Wang’s process] looked a lot like the ALC. However, it’s not the kind of thing where we could hire a journeyman Java programmer off the street, and give it to him or her and and have that person be able to really understand what it was doing.” IRS, he said, in effect would have replaced code it can still deal with, with code no one could.

That's good engineering management right there.

View on HN

"Excellent" engineering management for sure. Politically adept, sounds right to both business and technical minded folks. Sensible. And doomed.

> However, it’s not the kind of thing where we could hire a journeyman Java programmer off the street, and give it to him or her and and have that person be able to really understand what it was doing

A kind of false equivalency. You can't hire a "journeyman (any) programmer off the street" and have them understand the IMF or ALC. Or any complex app.

> IRS, he said, in effect would have replaced code it can still deal with, with code no one could

So don't do that. Keep the IMF source code and translate it or run on an interpreter. But - they don't want to do that! They are just beating around the bush saying they want a clean-sheet design. OK, then say that.

From the article:

> teams identify what it’s doing and document the rules. Then it gets passed to an architecture and design team that includes "very senior Java developers"

Doomed.

You could take the existing code, refactor it a piece at a time into more procedural code in a higher level language and make it more maintainable. If you try to reverse from assembler into OOA/OOD style requirements and patterns in one step and then implement it top-down. Everything by committee. Doomed.

> A kind of false equivalency. You can't hire a "journeyman (any) programmer off the street" and have them understand the IMF or ALC. Or any complex app.

That's true, but it's way easier to hire people to write in a language that's widely used and has other career opportunities. A language on life support isn't going to be attractive to the vast majority of programmers and with government pay so much lower than industry, low pay + dead end skills makes it very hard to hire. It's not like the engineering leader in charge of this project can just go ask for more budget to hire some rockstar engineers to knock this out, they're stuck with congressionally defined pay scales. So what they're doing is building their architecture and process around their organizational constraints. That's really good engineering management.

Oh, I agree it's good to have picked a modern language. And yes, I agree with doing it in a proper idiomatic style as opposed to java-in-name-only-basically-still-assembly. But the way they made the argument was disingenuous, I suspect expertly political.

No way could they hire engineers "off the street" and understand it right away, that's BS. They say that Wang's method couldn't do this, but slyly imply theirs can. That's what's false.

I think this is politics for "if we say clean-sheet re-implementation it sounds scary".

The problem is that it is and should be scary and instead of papering over it with cleverly packaged and admirable goals, they should come up with a real plan to do it. That's what makes me think, well excellent politics and strategy, but not-so-expert engineering and technical management.

I can't tell if you're being sarcastic or not. I figured transpiling would get you something that's at least black box testable using modern techniques. Then you start incrementally converting bits of it into idiomatic Java, adding more and more tests as you go. So it didn't seem like madness? But I've never done such a thing before, and am guessing there are a zillion problems with that approach. Not least that it would require an organizational commitment to stick with the conversion. Stop halfway through and sure you've got the opaque spaghetti they were worried about.

Not being sarcastic. They have working code and a staff of engineers that understand it currently. Transpiling it migrates the code to an intermediate state that no one understands, so why do that if you have to rewrite it again anyway?

> Not being sarcastic. They have working code and a staff of engineers that understand it currently. Transpiling it migrates the code to an intermediate state that no one understands, so why do that if you have to rewrite it again anyway?

If you have engineers that understand the old code, couldn't they just continue to maintain it in that form and transpile it until it's converted to idiomatic Java?

So what does the transpiling get you in that world? You can already run the old code on modern hardware (per tfa) and you already have people who understand the existing assembly to help do a rewrite...

> So what does the transpiling get you in that world? You can already run the old code on modern hardware (per tfa) and you already have people who understand the existing assembly to help do a rewrite...

Basically what the ancestor comment enumerated. It basically allows for a more conservative and incremental approach to rewriting things, since it would give you the ability to mix old and new code.

It seems like they plan to do some parallel testing, but if they used the transplier (and it was correct), they could probably do that at a much lower level (e.g. run both functions in parallel in PROD but only use the "old" functions results, log any discrepancies, you know you're done when there haven't been any for a while).

Reply on news.ycombinator.com