Author here. Did not expect to see this on HN at all. Just an engineering war story I shared.
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.
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.
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.
“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.“
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.
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.
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.
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.
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.
move fast and break things worked real well for the folks who got literally creamed while they were viewing the titanic.
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.
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?
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.
Again, maybe not enough to really matter, but enough to at least take into consideration.
Since the relative speed of the aircraft to the ship will be reduced.
Or are all of those tail hooks bespoke designs because reasons?
The model provided by -the manufacturer- correction NAVAIR (thanks OP!), stated that the cable will bounce up after having been hit by the landing gear. Thus the hook design made sense. The cable jumps up and over the hook. Plane arrested.
Instead, again as the article states, the cable is actually being pressed tightly against the flight deck and the elevated hook nose makes the entire hook get thrown up in the air when drawn over the tight cable, back towards the plane and would even destroy some parts of the monitoring mechanisms, so violently did that happen.
They also provide the new design, which is basically the old design and that is also why the techs that saw the new hook for the very first time (and know about the cable I presume) instantly said "That ain't gonna work!".
It's all in there.
I would actually love to know if someone on the hook design team questioned the model. I guess we won't know but I also it doesn't hurt to ask.
Like did someone go: odd, why would that cable go up and not tighten when waves are sent through it towards the outward attachments? But was inevitably shut down and didn't have "access to the customer" to ask/verify.
Like one of the first things to ask for when having to design this that comes to my mind is: I want high speed camera footage of current arrestor in action at the customer site!
As far as the little lip at the very tip of the hook- it looks to me like the initial design was trying to minimize any risk of digging into the flight deck and causing damage- this is just a guess though.
The next morning I went up on the flight deck before flight ops started and walked to the aft edge of the deck. I was looking for something and found it.
About one foot from the end, there was a single, shiny, brand new, solitary hook imprint in the deck.”
Each plane costs ~$100 million and the entire program will cost over $1 trillion when it's done. Performance needs are extreme: They need to land in all sorts of adverse, imperfect conditions - damage to the plane, the carrier, the wire, the personnel; bad weather; bullets and missiles flying around. It seems worthwhile to design the highest-performing tailhook for this plane, rather than to save a few bucks.
Also, IME people doing something this sophisticated don't miss those really simple, obvious issues that we happen to be able to observe and grasp from the outside.
Wildly different. For one the f14 is massive! And it's tail hook is like the size of a medium man
So yeah tail hooks vary wildy
Now, as a Ukrainian I do have a philosophical question of sorts. What we have seen here in a real full-scale combat is that some of the modern machines are way too delicate for actual operations on the ground. For example, I have heard some feedback about the Abrams tank: way too finicky for real use, not durable, not reliable. The same goes about many other western items. (Some hardware demonstrated exceptional reliability, like Bradleys and HIMARS)
My question is about modern fighter jets like F-35.
Does that level of engineering and the amount of delicate electronics somewhat limit the durability and reliability of the airplane compared to much simpler designs?
No one is even remotely contemplating sending F-35s to Ukraine. Besides and costs and security risks, the Ukrainians unfortunately have nowhere near the infrastructure and logistics to sustain such a complex platform.
Did nobody with practical experience with arrested landings look at the arresting hook design prior to this? Obviously computer models can and do predict extremely novel solutions to existing problems, but it's worth double-checking the model when someone with practical experience says "it will never work"
In this case, it seems like a simple slow-motion video of an arresting wire going under the wheels of an F-18 would have been enough to debunk the model.
But what about the many other cases where someone with "common sense" said "this fucker ain't gonna work" but the thing worked as predicted by simulations? Surely they must have happened too.
I mean... it's very likely that the answer is no. The last new carrier aircraft made was the Super Hornet - and that design was basically done by 1995 (the F-35 tests in question were in 2011/2012). That expertise would also be at McDonald Douglas/Boeing. Northrop Grumman has a long history of carrier aircraft development, but it would have been long dormant by that point.
I'm sure there's all sorts of reasons the model's inaccuracy wasn't caught before hand, but sometimes... if you're given a model that's someone says that's been V&V'd, and it produces a result that's only a little weird, you just go with it. There are only so many things you can add extra testing onto in a project. Sometimes you choose wrong.
Anyhow, consider that the model results were probably exactly what they were expecting. Remember that the designers would be honing in on the shorter tailhook. You can imagine their mental model going - "ok on legacy aircraft, we have flatter tailhooks because there's enough time for the cable to settle". And then going "ok, with a shorter tailhook, there won't be enough time to settle". And then their model comes out and say "ya, with the shorter tailhook, it won't have enough time to settle - it'll be UP IN THE AIR". Whereas reality is "ya, with the shorter tailhook, it won't have enough time to settle - it'll still be displaced DOWN".