Hacker News new | past | comments | ask | show | jobs | submit login

I see the "there's nothing wrong with old technology" comment a lot, and in this case I disagree. There's a good chunk of this thread pointing out how hard it is to hire for this position because practically no one is familiar with these technologies. This, to me, illustrates that there absolutely is something wrong with using old technology, especially in this instance.

I will grant that there are some things that just keep working and I also would be tempted to leave them in place. But if their functioning is critical then we either need to cultivate the necessary knowledge in our organization to ensure we can manage them adequately or replace them with something that the current market of people will be somewhat familiar.




That it's (now) uncommon technology is only a small part of the hiring problem. Anyway, what's the alternative here? It is almost certainly not worth the effort to rewrite everything in today's common environment 30 years into the service life of the jet; whatever you do now is going to be uncommon again.

A bigger part of the hiring problem is aerospace software, specifically military aerospace software is a difficult field to hire for. Clearance requirements limits your pool. Building weapons of war limits your pool. Low salary compared to other software job limits your pool. Very high level of process / low velocity of shipping limits your pool. If you require experience in the environment, rather than training otherwise appropriate candidates, that's going to be a limit too, but if you work in a specialized environment, you really have to accept that you will need to train people.


Bingo.

The current hiring model of "hit-the-ground-sprinting day 1" I suspect is largely the problem here and stems across many industries complaining about hiring difficulties.

Since this "best existing skillset match" hiring model businesses have widely chosen to adopt provide little-to-no on the job training, people will inherently focus on learning the most widely adopted skills of their target market(s) to increase their odds of finding a position in the labor market. Even niche skills will typically target larger proven successful niches and not target risky niches.

As a result, your business better follow industry and technology trends as they shift or you better start investing in your employees and maintain a positive relationship so you don't lose your knowledge assets that are likely undervalued by your business.

Even if Lockheed pays me double, even triple, my current rate, it's likely not worth it for me me wasting my time investing months to years in their specific architecture and fairly non-transferable skills acquired doing so since employer/employee relationships and loyalty are dead. That's a hefty investment on my side with little investment on theirs.

No thanks. It can sit empty and their project can fail for all I care.


I was recently considering learning the SAS data stack and decided against it for exactly this reason. However, I’m not completely convinced it was the right choice. Does anyone else have experience that could shed light on this situation?


The problem is of incompatible time scales. The original studies and requirements for the F-22 were done in the 1980s, Lockheed selected to build the F-22 in the 90s, F-22 entered flight test in 1997, IOC declared in 2005, expected to be in service until the 2040s at least. And in that time the world went from the original IBM PC to iPads and graphics cards that do real time ray-tracing.

And re-doing all the avionics would be a probably decade-plus effort costing billions of dollars. Cheaper to hire some old VAX guys as consultants, pay them exorbitant rates, and have them train up a new generation of VAX people.


The problem is of incompatible time scales. The original studies and requirements for the F-22 were done in the 1980s, Lockheed selected to build the F-22 in the 90s, F-22 entered flight test in 1997, IOC declared in 2005, expected to be in service until the 2040s at least.

Iteration time goes down by a lot in wartime. Also, choosing technologies which have much shorter iteration times could be a disruptive game changer. I'd bet shaped charge carrying drones with a range of 4 km would be much faster to iterate on than tank guns with the same range.


The technologies may have a shorter iteration time, but can the defense establishment adapt? I am skeptical but hope you are correct.


If I were Taiwan, I would be working with the US to engage in a crash program of developing AI drone mini-subs. Basically, develop the ability to make the waters around Taiwan exceedingly dangerous, even without air superiority.


Conscripts are the AI.


Thank you for that comment, @cmiles, I couldn't agree more!

I think that it's important to remember that there are both direct and indirect costs to "not changing something that's working".

If you don't keep abreast of change, then you're unable to be nimble enough to change when change is hugely advantageous.

Locking yourself into design decisions is usually cost-effective for the short term, but may be ultimately very harmful in the long-term.


Staying fresh has its own costs, and those would have to be made absolutely clear and transparent and clients must pay them. That's actually very difficult to do politically, especially when you have lowest-price bidding schemes.

Code is legacy the moment it's put into production. Keeping technical debt from piling up, and keeping on the bleeding edge to avoid costly maintenance of old systems is extremely expensive. And the costs escalate very quickly when you're talking about airplanes. The cost of dealing with legacy becomes acceptable very quickly.


The point is the F-22 is old technology. The testing and other tooling has been in production for a long time. And yes, it's hard to recruit people with the right skillsets to support legacy hardware and software.


> And yes, it's hard to recruit people with the right skillsets to support legacy hardware and software.

Perhaps you should not fire them, then.


How often do you rewrite your existing projects?


It's in my best interest to keep moving projects forward so that they continue to build and compile under modern environments and work with modern tools. I believe the cost of sticking with outmoded products or technology is to eat the training cost when onboarding new people (thus increasing the amount of time between hiring and getting them to work). We aren't all as wealthy as Lockheed who can (apparently) pay so much that they are literally talking people out of their retirement!

That said, I'm not flying airplanes over here. It's mostly business software. So there's that.


Also, unless you can prove that your software is EXACTLY the same after the ground-up rewrite, it will require changes to the voluminous and very detailed training materials, necessary to turn a 19 year old with slightly above average AFOQT scores into someone who can fix a complicated airplane on 4 hours sleep a night.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: