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.“
I used to work for Lockheed Martin. I believe it.
I found it so hilarious I was relieved when I finally got caught up in the layoffs.
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).
[0] 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...
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.
I note that the F-22 was primarily produced in Georgia. That usually isn't a swing state and it doesn't have a lot of representatives in the US House of Representatives.
The F-35 is produced in nearly every state, certainly including all the swing states. This is terribly inefficient, but probably kept the F-35 from being cancelled.
What.
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 aircraft. 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.
A. The "light" F/A part of the heavy/light fighter model.
B. Meant to save costs by having one aircraft with shared parts (across the three models) fill virtually all roles.
It's not totally crazy on the face of it- The expensive but undefeated F-15 and the relatively cheaper F-16 successfully pulled it off in the 20th century.
I imagine a couple of couches and a book shelf in a corner.
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.
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.
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.
(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... That involves a greater investment in code reviews.
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.
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.
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.
Nothing to see here folks, just the mold poking through the cracks of our public sector.
"Good news, General. We've found a way to lower maintenance costs in the cockpit systems by 10% if we removed this thing here on the blueprints, so we've already gone ahead with that change."
"But that's the emergency ejection system!"
"Yes, and our data indicates that it's almost never used. It doesn't really make sense to devote manpower to keeping a system running that few people ever need. If we get rid of it, we can free up developer-hours to making the canopy opening/closing action a little smoother. Everyone uses the canopy."
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."
Instead of having separate computers, you now tend to have fewer "servers" which run multiple modules in isolated partitions, communicating over the common network using unidirectional messages; whether using SAE AS5643 - aka IEEE-1394 - like in F-35 and X-47, or over mutated Ethernet known as AFDX (A380, A350, B787).
However a big portion of JSF issues is also in ground software - there's a dedicated set of platforms required to operate F-35, which is also known for infamously depending on connectivity to Lockheed servers or the airplane stops working.
The system involved, ALIS, had als infamously took more time to deploy during a test squadron redeployment than the whole redeployment - which I guess they might be trying to speed up using Kubernetes.
From what I heard ALIS appears to still be done the same style as certain other logistics software from lockheed back in 2010, and that doesn't say anything good.
They later talk about agile vs waterfall as well as devops. It doesn't read like this is going on a plane, probably just dev and test environments.
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.
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.
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.
I know Google has security teams, but what about the smallest company that has one?
I would be entirely unsurprised to find north korean telecoms/state government agencies using centos or debian. In fact if you google "north korea linux" you'll find that they already created their own weird custom GUI desktop distribution.
In the bigger picture, far more people use your code, whatever it is, to do useful and good things in random places in the world than people using it for purposes you find objectionable.
Isn’t it allowed to go further that sources access, what’s written on a piece of paper, and caring about ethics?
Does OSS contributors really needs to be so alienated?
