Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades • Hacker News Board

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#71

Post by vemv » Tue, Aug 13, 2019, 6:42 PM UTC

ergothus wrote: post #69

vemv wrote: post #53

Earlier quoted context omitted.

Great insight. I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind. Definitionally, no methodology makes the unavoidable avoidable? Now, let's say you get to that dreaded point - requirements have changed, dependencies have changed, the industry landscape has changed. Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?

> Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one? I feel this is a bit of strawman, though that may not be your intent. As I mentioned in the above comment, wanting to avoid hurting your long term for the short term is fine and admirable. However, I think the distinction between "unavoidable" and "avoidable" debt is somewhat facile and unrealistic. It's a continuum, with points…

Point taken.

At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective.

So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100% accuracy.

But I _can_ follow certain practices and have a given team follow them. Those practices being quite objective, benefitial, and superior to the status quo of the industry.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#72

Post by regularfry » Tue, Aug 13, 2019, 6:54 PM UTC

vemv wrote: post #20

Scrum has been a catastrophe to the software industry (argued elsewhere countless times) - I don't want to imagine the consequences it can have for jet figthers. For such environments you definitely want to have no deadlines at all, to have a special focus on well-defined requirements, and in software quality. That investment should be marginal compared to hardware costs. And in fact, by going more slowly, you end up…

No need to imagine, it's been done. Successfully. https://saabaircraftindustry.com/en/roads-to-new-capability/...

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#73

Post by regularfry » Tue, Aug 13, 2019, 7:00 PM UTC

vemv wrote: post #43

scarejunba wrote: post #35

Earlier quoted context omitted.

Iteration speed and quality are directly related, not inversely. Iterative development allows exploring software design considerations fast which means you get to actually good software instead of getting it right the first time. Fast iteration means you can kill ugly design. Slow iteration means you get stuck with a design choice because you discovered its flaws too late.

That seems entirely subjective. People may go fast for meeting a deadline, or for iterating as you suggest. Trying to determine what people do is likely a futile discussion. Finally, by writing decoupled, modular software, you are always free to reassemble it later (discarding/rewriting undesired parts), no matter when it was originally assembled.

This is something that has actually been researched, so it's not accurate to say it's subjective. Higher release rates (i.e. an iterative approach) cause higher organisational performance. See Accelerate, by Forsgren et al.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#74

Post by regularfry » Tue, Aug 13, 2019, 7:06 PM UTC

Glawen wrote: post #66

I work in embedded sw in the automotive world and I absolutely did not understand how container accelerates their development. Could someone here with experience in this things enlighten me ? F22 raptor is still an embedded system, I cannot believe that it runs a linux with container. What I am missing to comprehend this article.

Might it be a particularly bonkers toolchain for an obscure piece of critical hardware which needs containerising so whatever nightmare of an install process only needs to be done once?

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#75

Post by lucas_membrane » Tue, Aug 13, 2019, 7:13 PM UTC

Omigosh! The F-22 was the example of avionics software that worked, standing in contrast to the F-35 (sometimes) flying tarpit of tens of millions of lines of C and C++. Does this mean the DoD is now acquiring assured and acceptable agile-accelerated advanced armed airborne Ada avionics assets?

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#76

Post by ohaideredevs » Tue, Aug 13, 2019, 7:15 PM UTC

jki275 wrote: post #67

SkyMarshal wrote: post #64

Earlier quoted context omitted.

I always wondered why they couldn’t have just used the F-22 for both the air superiority role it was originally designed for and the multi-purpose role the F-35 was made for. The F-22 is more capable in every way, and more survivable with dual engines. They would have needed to figure out vertical take-off/landing version of the F-22 but I’m sure that was not impossible. It may have looked more expensive on paper wit…

The F22 was designed in the 80s. It's old. It's fast, certainly the best in some aerodynamic ways, but nothing like the capability the JSF brings in computing technology. In addition, the threats anticipated that led to its development never materialized. That's why it was cancelled.

>but nothing like the capability the JSF brings in computing technology.

What computing technology can't be put into the F-22? Iirc it has a much bigger radar housing, and EO DAS (fancy term for 360 IR / situational awareness) can be added to it.

To answer the parent term - the F-22 was used for air-to-ground in the middle east, so it can definitely fill that role. There was also an attack plane/bomber variant proposed.

With that said, I don't think "its old" holds.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#77

Post by ohaideredevs » Tue, Aug 13, 2019, 7:16 PM UTC

detritus wrote: post #63

jedberg wrote: post #54

Earlier quoted context omitted.

Keep in mind the military has a history of claiming they stopped production and then producing them in secret or producing a slightly modified version as a way of making our enemies think we have fewer weapons than we actually have.

Ooh, do you have any articles on this? Sounds interesting!

Stealth Blackhawks (pretty much confirmed by the Bin Laden raid) are definitely an example of the cancelled Comanche program tech going into black projects.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#78

Post by foobarrio » Tue, Aug 13, 2019, 7:22 PM UTC

vemv wrote: post #38

smileysteve wrote: post #32

Earlier quoted context omitted.

> when you enjoy zero tech debt and an excellent foundation. This implies that you plan exactly when and where tech debt is accumulating or found. The scrum argument is that by iterating and releasing, you find out where unexpected tech debt is more rapidly; and you go back and fix it. One way that #AgileIsDead happens is when products disregard the tech debt for features even as it becomes apparent.

Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it. (I'm open to be convinced) Generally I have witnessed tech debt as something pretty blatant and obvious - generally it's detected in the code review process. Sometimes it's big faults being introduced, more often it's small faults leading to 'death by a thousand cuts'. My current policy…

One of the reasons why I sometimes don't like the term "tech debt" is because you can take it on without knowing it. This is not true for financial debt. When you borrow money, even if you're not tracking it, the lender is 100% tracking the debt.

If you are in a team that discourages upgrading build systems, code reviews, code quality, testing etc there isn't really anyone that can point to instances where tech debt was accrued or how much there is.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#79

Post by jandrese » Tue, Aug 13, 2019, 8:14 PM UTC

checktheorder wrote: post #55

jandrese wrote: post #41

Earlier quoted context omitted.

It was supposed to be the next generation F-16. The lightweight single engine jack of all trades fighter that could be exported to other countries to help defray development costs. There was even a notion that you could use the same plane across all branches of the military so the same supply chain could be used for all three and you could build them in higher quantities to spread the development costs over more airc…

>But then of course the aircraft got saddled with requirements from three different branches of the military at once which made it extremely difficult to design and build and thus very very expensive. Sounds rather like the Space Transportation System. During design, it went from a compact inexpensive passenger shuttle with modest payload capability, to a complete pig of a ship. And all because the Air Force contribu…

An extremely important part of project management is the ability to say "no", even if the customer is bringing extra money to the table. Extra requirements have a way of increasing costs in an exponential way and it's very easy to lose sight of your original goal.

Of course this is a problem when you have Congress breathing down your neck and looking for any excuse to cut your program. One big advantage of skunk works projects is that they keep you firewalled off from idea men.

Re: Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades

#80

Post by twodave » Tue, Aug 13, 2019, 8:18 PM UTC

Retric wrote: post #49

vemv wrote: post #40

Earlier quoted context omitted.

Would you rather have a bug-free fighter delivered in 2021 or a buggy fighter in 2020? Especially considering that many codebases are expected to have a shelf life of 5-10 years. IME working deadline-lessly doesn't mean you're suddenly knee-deep in a metaprogramming rabbithole. You just do the same stuff, stress-free.

That suggests a 2021 deadline, but many military projects have been 15+ years late. A 15 year old fighter is already in need of updates.

There's a healthy enough difference between an estimate and a deadline, I think. Obviously you want to report progress, but you can do that and work productively more effectively without a deadline, because now you're no longer feeling pressured to lie to yourself and others about what you are capable of.