3 ms·

This is really cool, thanks for sharing. What's wild to me is that the program started in the late 90s and only now is the F35 fleet up to originally specified?

by tra3 3y ago

This is really cool, thanks for sharing. What's wild to me is that the program started in the late 90s and only now is the F35 fleet up to originally specified? operational capacity. Since then I graduated high school, got a degree, got married etc etc. The time span is mind boggling. Would be interesting to see how continuity is maintained for so long. In software it feels like if a project is more than 6 months old, we throw it out and rewrite it.

tekla 3y ago
You write shit down and you have career engineers that enforce continuity It's trendy in software to complain about doing annoying work like writing reports and documenting things. But most hard tasks require writing reports and documenting things.
- eitally 3y ago
  And this isn't limited to aerospace. My wife has spent a career in pharma (drug save & pharmacovigilance specifically) and it's the same way there. People complain about rigidity and sluggishness in these industries but there absolutely is an ingrained attitude of documentation and process compliance that pervades. At one point -- and this was just last year -- my wife took over running a monthly safety report that involves manipulating a bunch of data in Excel. Even that has a 9 page instruction guide, and since she now owns the output she also owns maintaining the manual. Too often in the land of software we underestimate the potential negative impact the traditional "move fast and break things" approach to product development can have when it comes to real world use in mission critical systems.
  - trhway 3y ago
    On the other side this unwillingness and mental non-acceptance of those reports/manuals/etc. as a wasteful activity frequently comes from the understanding that there are more efficient ways of doing things, and that drives the "software eating the world" effect. While I naturally don't know the details of the case you mention and pharma is far from the domains I've been in, yet in many business/enterprise situations the software approach is to code the many-page guide into business logic, including ETL-ing the data instead of manual import, etc. Move fast and break things brings you to the Moon in a decade using primitive tech, where is total process compliance can't do that even in 50 years using much more advanced tech.
    - red-iron-pine 3y ago
      a lot of people died in germany, the ussr, and the us making those rockets work. and in exchange for that we planted a flag there and have a handful of rocks in a glass viewing box. move fast and break things worked real well for the folks who got literally creamed while they were viewing the titanic.
    - falcolas 3y ago
      So, an amusing anecdote related to your second paragraph - one reason it's taking so long the second time around is everything has to be repeated. They lost the knowledge of how to make rocket stages and engines of that size, and had to re-learn those lessons. It's also quite important to remember how many lives were lost (or nearly lost) because of "breaking things" in the Apollo program. Something that's not nearly as acceptable today than it was at the height of the cold war. Something that directly implies moving more slowly and being more sure that everything works the first time, every time.
      - inamberclad 3y ago
        Seconded. People burned alive until we learned. Surely there is a middle ground that will let us speed up while staying fairly safe, but it's important to remember that outside of software, many rules are written in blood.
        doctor_eval 3y ago
        I don’t hold a strong opinion either way - in terms of process and documentation versus freestyling it - but that fire was predicted, and I think the concerns were documented. It can and did happen again, twice, on the shuttle project. Both the O rings and the ice damage were documented. Ultimately, any process (or lack of process) can be subverted by a bad culture. And unreasonably excessive process - as perceived by the participants - can damage culture as much as not enough. The problem is that culture is ineffable, so we try to nail it to the ground with whatever we can think of.
- hanche 3y ago
  Heck, even maintaining my computers at home requires documenting things! I have lost count of the number of hours I’ve lost trying to rediscover how or why I set things up the way I did.
roughly 3y ago
> In software it feels like if a project is more than 6 months old, we throw it out and rewrite it. I think that would be a bad way to operate, but what's worse is what we _actually_ do, which is write the project like it's gonna be replaced in 6 months and instead keep that poorly-documented untested duct-tape contraption around for a decade as the central load-bearing component of critical infrastructure.
- Jenk 3y ago
  A decade is infancy in that scenario. The world's economies are running on stuff way, way older, for example.
xattt 3y ago
> In software it feels like if a project is more than 6 months old, we throw it out and rewrite it. “The Phoenix pay system is a payroll processing system for Canadian federal government employees, provided by IBM in June 2011 using PeopleSoft software, and run by Public Services and Procurement Canada… By July 2018, Phoenix has caused pay problems to close to 80 percent of the federal government's 290,000 public servants through underpayments, over-payments, and non-payments.“ https://en.wikipedia.org/wiki/Phoenix_pay_system https://en.wikipedia.org/wiki/Phoenix_pay_system
jonp888 3y ago
I work on software that has a lifetime once installed of about 30 years, and if a safety critical error is found during that time, ideally it needs to fixed with a minimal patch, so we have to maintain the capability to do so. I guess the ethos is quite different to top tech company. We don't get the pay or perks that you would get in Silicon Valley, but we are unionised, and it's a viable option to spend your entire career just on one project so it's very stable. Partly it depends on documentation, but also on thinking long term. There are certain people who are the technical authority for a particular area, and they know that about 5 years before they retire or move on they need to find someone who can take on their role for at least the next decade, to keep their knowledge rolling forward.
- tra3 3y ago
  That's fascinating. Is it possible for you to share more details? Industry? Tech stack? If your project started 30 years ago, that means DOS, or Network or maybe one of the IBM behemoths? Then the maintenance includes pacing OS updates and dependency changes?
  - HeyLaughingBoy 3y ago
    Not OP, but I work on medical devices. One product at my last job had an expected service life of 20 years. FDA requires that the manufacturer maintain the ability to support and service a medical device for, IIRC, 5 years after market exit. In the 10 years after release that I was on that project, we went through multiple OS upgrades from Windows NT to XP Embedded, to Windows Embedded Industry (replacement for XP Embedded) and a number of replacement x86 CPU boards had to be qualified as one manufacturer after another exited the market. Since the device is validated as a complete system, we often had to buy a year or two stockpile of existing product to give us time to start the Validation process for replacement hardware. You usually have plenty of warning from a supplier that a product (Windows or a CPU board) is going EOL at a certain point, so you need to start validating whatever the next replacement will be well ahead of time.
euler_angles 3y ago
The F-35 contract was awarded on October 26, 2001. I was in my freshman year of undergrad, 18 years old. I started on the program in August, 2010. I was 26 years old. The program has just completed its Initial Operational Test & Evaluation, including its runs for score in the Joint Simulation Environment. I am 40 years old.