
Lockheed Martin Taps Red Hat to Accelerate F-22 Raptor Upgrades - teajunky
https://www.redhat.com/en/about/press-releases/lockheed-martin-taps-red-hat-accelerate-f-22-raptor-upgrades
======
wikibob
This is pretty hilarious. So some consultants swooped in, there was 8 weeks of
training, and now everything is going to go back to how it was.

Source: seen more than one of these external “transformation” efforts.

“ Through an eight-week Red Hat Open Innovation Labs residency, Lockheed
Martin Aeronautics replaced the waterfall development process it used for F-22
Raptor upgrades with an agile methodology and DevSecOps practices that are
more adaptive to the needs of the U.S. Air Force.“

~~~
wil421
“Colonel, instead of requirements you’ll call them user stories.”

~~~
dmix
And don't worry there's even _more_ mandatory meetings than before.

------
ohaideredevs
"The Lockheed Martin F-22 Raptor is one of the world’s premier fighter jets,
thanks to its unique combination of stealth, speed, agility, and situational
awareness."

A huge understatement. It's the only true 5th gen that's tailored for
performance, rather than cost savings (ala the F-35). The others are
completely unproven (Chinese) or both unproven and in extremely limited
quantities, while not providing true stealth (PAK FA, though if anything, the
SU-35 family is the closer analogue).

~~~
consumer451
I’m not a huge fan of obscene military spending, but the cancellation[0] of
F-22 production must be one of the most boneheaded decisions I’ve seen in US
military procurement. I must add the caveat that I have no security clearance
so there may be other factors.

[0]
[https://en.wikipedia.org/wiki/Lockheed_Martin_F-22_Raptor](https://en.wikipedia.org/wiki/Lockheed_Martin_F-22_Raptor)

> Service officials had originally planned to buy a total of 750 ATFs. In
> 2009, the program was cut to 187 operational production aircraft...

~~~
SkyMarshal
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 with ideal assumptions to produce
lots of expensive F-22s instead of a few F-22’s and lots of cheaper JSFs. But
in practice I bet the costs would have equalized, due to the increased volume
of F-22s and the development of extensive institutional knowledge of that
airframe - from manufacturing to maintenance to piloting/operating.

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

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

~~~
jki275
JSF has sensors built into its skin. You don’t just retrofit sensors onto an
LO platform.

Retrofitting new computing technology into an aircraft is a huge deal. Just
getting a data link into it so it can talk to the rest of the DOD has taken
over a decade and I’m not sure it’s even complete yet.

Yes, it’s old. That doesn’t mean it’s not useful, the F15 is far older and
still in use and will be for decades, but it was more cost effective to put
the money into the new platform instead.

~~~
ohaideredevs
I don't mean to get into the weeds here, but what part of EODAS can't be added
by literally putting a thermal camera (from the F-35 program) in several
places on the F-22 and running wiring to it?

I completely understand that it interfaces with the helmet. I also know that
it took ages for the F-22 to get a simple FLIR built in, but if even a
fraction of the F-35 resources were directed at the F-22, this would all be
more than doable quickly.

As far as I am concerned, the selling pitch of the F-35 is the STOVL and
EODAS. At that point the F-22 could be fitted for carrier operations, because
no one uses VTOL (or plans to) on the F-35 anyway except for moving it around
parking lots with no ordinance.

Again, this is ignoring all the political info.

Also, to get more specific, I don't know of any "sensors built into its skin"
\- EODAS is just a bunch of little pods with thermal cameras and fancy
computing. Obviously don't tell me if it's something that's not public
knowledge.

~~~
jki275
No.

The main function of the JSF is situational awareness. The F22 doesn't even
have a functional data link yet. JSF has all of it built in from the
beginning. Everything you add to an airframe costs millions of dollars, and
there's no point in doing it.

STOVL is an important part of the JSF program. The F22 isn't capable of doing
STOVL or carrier operations, you don't refit a non-CVN capable aircraft for
carrier operations.

~~~
burfog
STOVL can certainly be retrofitted the same way lots of things are: as an
external pod.

Guide the pilot into a suitable position above the landing area. (with visual
indicators, much like those for a bombing run) Once the plane is in the right
spot, a computer finishes the job with full automation. The aircraft is
stalled. The pods fire rockets. The aircraft is guided down and brought to a
stop.

This retrofit would be particularly sensible for the F-15, which normally
carries conformal fuel tanks. That would be a fine place to install the
retrofit.

~~~
jki275
LOL.

Sounds like a great thing for a scifi novel, but not useful to do something
like that in real life.

~~~
ohaideredevs
It's been done:
[https://en.wikipedia.org/wiki/JATO](https://en.wikipedia.org/wiki/JATO) The
primary requirement for a carrier jet is two engines, decent thrust, and
enough body rigidity to take landings. The F-22 has all that. The MIG-29 had
less, and had a carrier version. Same with the SU-27.

~~~
jki275
JATO is for takeoff, thrust in the aft direction is not the same as trying to
rocket assist a landing. Completely different. It's also extremely hard on
airframes.

The idea is not feasible.

Also your list of "carrier aircraft requirements" is incorrect, the JSF is a
single engine aircraft, and landing gear is a major requirement of a carrier
aircraft. The F22 is not a naval aircraft, was not designed to be, and never
will be.

~~~
burfog
He is correct about carrier aircraft requirements. The navy was forced to
accept the JSF.

As produced, the F-22 is obviously not a naval aircraft. The tail hook is
single-use, the landing gear is not reinforced, and the more modern stuff for
carrier approach is probably not installed. All of that would be easy to
change, and in fact a carrier version was proposed.

~~~
jki275
The Navy spearheaded the JSF for both its CVN fleet and for the USMC. The JSF
is not the first single engine Naval aircraft, and its engine is reliable
enough that it's not an issue. People look at the tomcat and hornet and make
up requirements that have never existed.

There is no such thing as "easy to change", you would have to redesign the
aircraft from the ground up. You don't "navalize" an air force asset, you have
the air force use Naval aircraft if you want dual use. The F22 is not and
never will be a carrier aircraft.

------
Sil_E_Goose
I worked at Lockheed with Red Hat doing exactly what they are talking about
here on the F-35. Unsurprisingly, It was a total disaster from the top down. I
guarantee this will be as well. I was happy to get out after a year.

~~~
stickfigure
Please elaborate! You seem to have direct relevant knowledge but this tweet-
length jab doesn't add much to the conversation. Even just a couple paragraphs
would help us all understand.

------
mtmail
"By knocking down walls and creating open spaces to work in its new dojo,
[...] team now has a dedicated space for continued learning, thinking and
problem-solving [...]"

I imagine a couple of couches and a book shelf in a corner.

~~~
kevin_thibedeau
Why not a crusty VBSS black belt duking it out with these agile newcomers.

------
cameldrv
I'm a little bit surprised to see this.

One thing I've observed working on many different types of software projects
is that there exists a continuum between waterfall and agile/scrum, and one
way of thinking of it is what the length of the sprint is. Waterfall is a
single sprint the length of the product, spiral development is several sprints
over the length of the product, and agile/scrum is sprints of a couple of
weeks to a month.

The length of the sprint is simply the length of the planning cycle. What I've
observed is that systems with certain characteristics, such as safety critical
systems or systems that involve hardware that doesn't yet exist or is
expensive or time consuming to test typically don't work with an agile/scrum
planning cycle. If you want to deliver them in a reasonable time, complex and
parallel requirements mean that you must plan things far in advance so that
everyone is ready at the same time.

------
vemv
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 delivering faster after a couple
years, when you enjoy zero tech debt and an excellent foundation.

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

~~~
vemv
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 is to allow zero tech debt, following the "no broken
windows" principle. [https://pragprog.com/the-pragmatic-
programmer/extracts/softw...](https://pragprog.com/the-pragmatic-
programmer/extracts/software-entropy) That involves a greater investment in
code reviews.

~~~
ergothus
> My current policy is to allow zero tech debt

I was in an office that had such a policy - it didn't go well. Perhaps it's a
matter of definition, because:

> I hadn't heard of tech debt being something so subjective/invisible that it
> just creeps in and you have to discover it.

Tech debt is _inevitable_. Any decision will eventually be debt - rot begins
before the code is even finalized. Focusing on avoiding short term gains at
long term cost is totally fine, and I think that's the point of your "zero
tech debt" strategy, but that's not zero tech debt. And even when maximizing
for the long-term, you're picking between options, which means you're picking
the FORM of your tech debt, not the existence of it.

To return back to my (admittedly anecdotal) experience with "zero tech debt":
What happened was a language shift. People would avoid the phrase "tech debt",
but still dealt with the reality. The decisions were being made, uncovered
debt (such as a paradigm shift in the industry, or a change in dependent
technology, or just an anticipated business flow that turned out to play out
differently) was hidden. Basically, it seemed fine for a while, but management
was getting out of the loop because management had decided an unachievable
purity was more important than frank and open communication. The result was
what happens any time management pushes themselves out of the loop - at some
point, the compound interest on the debt came due. By then, multiple devs had
left because in an industry with so much choice, why choose to work somewhere
that refuses to face reality?

Not selling the long term for the short term is a great approach, but if
you're trying to enforce "zero tech debt", I suggest you talk with your devs
to see what they think that means and make sure that you're all on the same
page, because tech debt is maintenance costs, and those will never be zero. If
you're being told they are zero, then there may well be a disconnect.

~~~
vemv
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?

~~~
ergothus
> 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 scattered throughout the center. Is this
decision the best one? That is debatable, and should be debated, but the
result won't be "yes debt" or "no debt".

I also said that if someone is shooting for "Zero debt" they should talk with
their devs and make sure everyone is using words to mean the same thing. I
continue to stand by that, because however clean and rational your personal
definition may be, it's worthless if that's not the meaning anyone else is
using.

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

------
natpalmer1776
So a government contractor subcontracts another government contractor's new
acquisition to do some unnecessary, yet likely expensive, consulting work that
has no net benefit to the project.

Nothing to see here folks, just the mold poking through the cracks of our
public sector.

------
orliesaurus
I bet somewhere on Redhat's sales pitch deck there was a mention of "1 - click
deploy updates" slide, somewhere, for sure.

------
ThreeFx
Am I reading this correctly as Kuberetes-powered fighter jets? That's
certainly not going to shoot anyone in the foot...

~~~
vipa123
I agree that Kubernetes-powered fighter jets is a bad idea, bordering on
catastrophically bad. That said, I assume they'll be using Kubernetes as a
development and test platform -on the ground- to produce some form of binary
output that would go on the plane.

~~~
throwaway5752
If it's any k8s distro let it be openshift. Best selinux integration.

That said, how can you not wince reading, "To do this, Lockheed wanted to
adopt principles and frameworks common in software lexicon like agile, scrum,
minimum viable product (MVP) and DevSecOps."

~~~
ThreeFx
Flying on MVP software must surely be exhilerating.

~~~
heavenlyblue
If you read MVP with a German pronunciation of V then you get Minimum Flyable
Product.

------
lucas_membrane
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?

------
PedroBatista
Now that IBM owns Red Hat, we should get used to these hilarious/tragic
"success stories".

------
rurban
During an "enablement session" really? This is a sales jargon AFAIK, the
developer-unfriendly term for "hands-on training". Such jargon shouldn't be
used in agile.

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

~~~
regularfry
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?

------
walrus01
what the hell is DevSecOps?

I've been doing network security for twenty years, so I know what that is,
this just sounds like some marketing and sales people started mashing
buzzwords together.

~~~
freehunter
DevOps is mashing development and operations together. But that ignores
security, often putting security reviews after the code has been deployed or
at least after it's done being written, which necessitates re-work. DevSecOps
makes sure security is a part of the development and operations work.

Yes it's a re-wording of an existing concept. No, it is not a new idea. Yes,
it is important enough to call it out because so many companies _don 't_ let
security/operations/development work together.

You're not the target audience, your CISO or CTO is.

~~~
heavenlyblue
What is the size of the company when CISO, on average - exists as part of the
company?

I know Google has security teams, but what about the smallest company that has
one?

~~~
freehunter
Whether a company has someone with the title "CISO" or not matters very little
to how they design security into their products. The term "DevSecOps" is
designed to eliminate the need for a discreet "security" workforce.

To answer the question more directly: I've worked with 10,000+ employee
companies with no CISO and I've worked with <1,000 employee companies with
separate CTO, CIO, and CISO roles. At the executive level, job titles are more
of suggestions than strictly defined silos. It all depends on how the company
is organized and what their strategic priorities are.

------
jedberg
That IBM acquisition is starting to pay off.

------
m_b
Not proud that open source I contribute to help USA kills people, it really
sucks.

~~~
cronix
I'm sure there are many, many others being used, that you aren't aware of. Do
you really think the US Military are the _only ones_ to use redhat, or mysql,
or any other major opensource project in their weapons of war and surveillance
programs? You're contributing to a lot more than you think you are, and
supplying _every_ side with the tech. It's free for anybody to use, even
terrorists and nation states.

~~~
homonculus1
In general the world is infinitely interconnected and any tool can be used for
good or evil. Don't sell powerful technologies to oppressive governments, but
it's also pointless to lose sleep over nth-order relations to bad people doing
bad things.

