Hacker News Reader

Comment by engi_nerd | Hacker News Reader

The gun has been tested on the ground both in and out of the plane. The software that would enable full use of the gun was delayed at program office request. It was decided that using missiles and bombs was more relevant and important.

I get that you don't like the plane but your arguments do not reflect facts.

View on HN

My argument is the gun software is not the ready which you have confirmed. Also, for a CAS platform the pathetic 220 rounds is really going to be a problem.

http://www.dodbuzz.com/2015/01/08/pentagon-f-35-gun-will-fir...

Yup, there's no denying the software is not ready. As I pointed out, the gun is still being tested.

And let's be clear about that 220 rounds -- that's only on the F-35A. The number is less for the other two variants (180) which have to carry the gun externally in a pod. So that is even worse!

You just admitted what the article claimed but with a different reason. We've spent X dollars for Y years for a plane with a partly usable gun? That fact is enough reason not to like the plane for situations involving guns or the program that led to that situation. That's before my arguments or personal preferences enter the situation.

So you're a software guy, right? Ever do a phased release? Wherein you design capability to be released in different increments. I know this isn't the most popular of software methodologies, but it's how defense projects work. Your complaint is like saying, "You worked all this time to get to phase 2 and you don't have feature X done yet?" and the engineers say, "But feature X isn't even intended to be in the software until phase 4!"

EDIT: I should point out that as a defense acquisition project, THIS (http://www.hjspllc.com/2014dev/wp-content/uploads/2014/04/DA...) is what governs the F-35 and most projects the DoD does. Look upon these works, ye sorry engineers, and despair. I took several hundred hours of courses about this process and I could not even begin to explain it, it's so ridiculous.

Tons of waterfall and spiral development there.

I'm a systems & software guy w/ a high assurance focus so I'm familiar with that sort of thing. It taught me to prioritize based on what was more vs less critical. So, it's supposed to destroy targets. Means it has to take off, detect the target, destroy with missiles/guns, and return. The essentials of these get done first and then everything else.

A program that's spent this money with this many features without a working gun is not how we do phases in delivery. That's defense programs gone wrong. Further, the other commenter's link shows this isn't a phase: it's a delay caused by the failure of one. Plenty of delays, overruns, and even decommissioning to make up for it support how poorly-managed this program is. And such poor management and priorities support that this isn't merely a lifecycle issue.

Well, you would have to prioritize how you wanted to kill targets, as you say. The program has chosen to delay focus on the gun until later. Was that a wise decision? I honestly don't know.

And also, history nerd that I am...most of the high profile defense programs that I can think of were off the rails at one point or another. This is not to excuse anything (boy, people love that argument, that other programs had issues but turned out fine, so this will, too...I don't like that one), but to point out the fact that we as a society really don't understand how to do this kind of thing well. F-15 and F-16 were both lampooned in their day as being bloated and late and ineffective (I can anticipate the objection now -- not to this same degree -- and cannot argue against it). The Bradley's problems were so famous that HBO made "The Pentagon Wars" (which is a movie that I would actually highly recommend). The A-10 was not paid much attention to publicly but the Air Force of the 1970s hated it and wanted it to die before it ever left a drafting board (they were wrong, of course).

I was saying the program has had many delays and overruns in general with the gun issue maybe being part of that trend rather than pure design decision. Each possibility paints it in a different light.

Regardless, I agree that many programs have had issues despite making it. I did watch Pentagon Wars and was amazed that some issues even existed. I think the main concern, outside the original link, is that this plane is one of the most expensive we've ever done while not delivering the value or effectiveness a few different, focused planes would. They still could've consolidated on radar, comms, weapon/missile systems, and so on while making the plane physically ideal for its missions. In process, they could leverage proven approaches in other best of breed fights.

That is what I meant by upgrading our current best stuff. You can straight-up improve their existing configuration. Or you can create new planes with their best qualities with vastly improved capabilities. As illustrated above, there's still plenty of consolidation allowed and would probably be cheaper (in development) due to less troubles.

Well, from my experience, the low-hanging fruit with improving existing configurations has mostly been done. The Navy has taken the Hornet to its logical full development potential by orchestrating the creation of the Super Hornet, which is more than a simple 15% scale up, it's a whole new airplane. The Super should serve for the next 25 years or so. Although the Navy is beginning to do the initial studies for its replacement...

One thing that constrains a lot of the older aircraft is electrical power. They don't have the big generators and high voltage DC power systems that the newer jets have. Those newer systems provide a lot more power budget for running all the advanced sensors. Now, I suppose you could add this capacity to older aircraft, but that's expensive because all this is really tied into the engine and would require some extensive mods. That means time out of service, and tying up depot maintenance. Maybe this is worth it in some cost/benefit comparisons -- I haven't really done the math. Just trying to point out a big gotcha in upgrading that most people don't often think about.

See, now you're getting to the kind of stuff I'm talking about. They need more power budget. Other things about them are pretty good or easy to update. So, do a clean slate design following the other plane's strengths as much as possible while adding the new stuff. The result is not the same plane. Yet, it should deliver more value than a basic upgrade of old plane while having way less risk than a program requiring tons of R&D (eg F-35).

Now, my proposal doesn't negate the possibility of investing in next-gen tech. The F-22 program didn't bother me because we have to push ourselves as far as possible in any specific area. The results usually trickle down into other, affordable tech. F-35, far as I can tell, benefited a bit from that program. The U-2, SR-71, B-2, and F-117 all offered unique capabilities. Just prefer that the majority of our fleet is cost-effective and value-driven. Leads to build on what's proven.

U-2 is probably one of better investments given it's apparently still paying off (see below). Could probably use that F-35 sensor system & some control assistance for pilots. However, it could all just be an excuse for local Majors to jump in GTO's and tear up the tarmac. ;)

Addressing your first paragraph, I have the feeling that the F-18 E/F Super Hornet is a real-world example of what you're talking about. A good airframe (the legacy F-18) was taken as the baseline for a new aircraft that featured greatly improved systems in all areas (including electrical power generation!). Does a Super Hornet deliver more value than a legacy F-18? Absolutely, I don't think anyone familiar with the type would argue otherwise. Anecdotally, all my friends with experience on both ranges of F-18 love the Supers. I've never touched them on any kind of engineering project though.

But the Super Hornet was not risk-free (not that you implied such a program would be, I feel that you gave the concept a fair shake). It encountered some problems that almost killed the program. Here: http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=ht... Click on the link next to "PDF url" to obtain the report. This is a study of what almost wiped out the program...Trans-sonic wing roll-off, aka "wing drop". Much more readable article here: http://www.nasa.gov/centers/langley/news/factsheets/F-18.htm...

The cause was a difference in the wing-fold in the larger Super Hornet as compared to the original Hornet.

You never know where risk can come from. You can, as you are no doubt well aware, try to schedule some risk out of the system, and design risk out of it, but it's always there. This is not an argument against your point -- after all, the F-18 E/F is a real world example, as I said, and a successful one -- but pointing out some of the caveats of it. Even things that seem like they should be simple can turn out to be complex. A lot like software...

Actually, I agree the Super Hornet is an example, maybe the best, of what I propose. The results show it delivered on my promise as well. It's no surprise that they ran into problems. Matter of fact, the problem is a common one in system evolution: assumptions built into use of components in version 1 no longer apply in version 2 but it wasn't taken into account. IIRC, this was the same reason for the failed conversion that destroyed the Ariane 5 rocket. The receiving component assumed and was coded for a smaller number, resulting in an overflow.

This is why I'm a fan of keeping unambiguous, mathematical specifications (eg Z) side-by-side with readable, English description side-by-side with design. The specs should embed assumptions, maybe more visibly than other things. We've seen this in software with both Eiffel/Ada's Design-by-Contract and static analysis tools with similar pre- and post-conditions. You could say typing also helps. The person using a component should be able to readily tell what its requirements were and do a manual/automatic sanity check.

Personally, I'd be surprised if your CAD tools for aerospace don't have requirements or integration checking features built into them. F/18 started around the time that such tools would've both been feasible and had computers that could run them fast. Do they seriously not have ways of catching at least obvious problems with component reuse?

I agree with you about problems in system evolution. We both see this in our work. And about that Ariane incident, you're also right. More detail here: https://en.wikipedia.org/wiki/Cluster_%28spacecraft%29. For anyone interested, I can recommend this book: http://www.amazon.com/Space-Systems-Failures-Satellites-Expl...

Your second paragraph sounds like a call for literate engineering, akin to Knuth's literate programming. I like this idea.

About CAD tools for aerospace, it really depends on what CAD tools you use. Things like Pro/E and Solidworks explicitly allow you to put in specifications and tolerances, and also for interference checking and the like. For electrical design, there are tools that allow you to put in electrical requirements and run simulations on your design files to test against those requirements. So there are some ways of catching problems ahead of production.

Now, those tools aren't available to everyone. So I'm on job #3 in this industry. Job #1 had me doing all my electrical designs in AutoCAD LT. No checking or simulations there (can't even generate a bill of materials with this either)! All we had was a library of symbols that one of the engineers had made. Job #2 had me using Cadence ORCAD, but without any of the add-ons that made it useful (could generate a BOM, but couldn't customize it, which meant that I was assigned to create an Excel macro to customize the BOM to meet our specific stock-keeping system's requirements). Job #3, I have nothing because all the vast majority of the electrical designs are done somewhere else (they use CATIA). Whenever I actually do some design work, I'm reduced to taking screenshots of relevant areas in other schematic PDFs, then stitching them together in MS Paint, and then pasting those into a Powerpoint template. I wish I were kidding.

But with job #3 most of my time is spent on other things besides pushing dots, like testing and evaluating upgrades to our embedded systems (this kind of thing is one reason why I spend time here).

Wow, that's ridiculous and sounds painful! Again, I'm not a hardware guy, but I've absorbed a lot of knowledge and wisdom of it over past year trying to improve CPU designs and eliminate subversion possibilities. Studied their flows, synthesis, mask reduction, etc. Anyway, what your describing sounds behind even the free stuff. So, here's an amateur's attempt to help you out a bit with open-source alternatives:

gEDA's 10+ tools to assist the process https://en.wikipedia.org/wiki/GEDA

KiCad is similar w/ bill of materials and artwork https://en.wikipedia.org/wiki/KiCad

QUICS for simplified usage in schematic capture & simulation https://en.wikipedia.org/wiki/Quite_Universal_Circuit_Simula...

Magic for those wanting old school (a recent SOC used it) https://en.wikipedia.org/wiki/Magic_%28software%29

You get used to something like gEDA or KiCAD then you can use it (even on your laptop) whenever the work tools suck. Not sure if it will help you since I understand just enough to know the tools exist and what they do but nothing further. And if you get bored with hand-made circuits, look up Qflow: from behavioral synthesis down to detail routing all in open source. Handles much of opencores.org's Verilog.

Have fun with that and please tell me if any of the CAD tools are solid replacements for commercial use in your field.

I do have a laptop at work that I can use to mess around with. I can't work on any classified materials on it (but I don't deal with that much on the design side).

I will experiment with these tools when I get some time. I doubt if you'll see a reply to this thread by then, though. Perhaps we can find another way to communicate.

Seems every variation of my name and what it represent are taken on all major email providers. Hard finding one that represents strong INFOSEC, lay people understand, easy enough to spell, and sounds cool. Then, I had an idea. Just click on my name to see my new email for security work.

I have enough experience with phased development to know that the later phases rarely happen.

Or they get mashed together, or neutered, or otherwise transformed to poor shadows of their original conception.

? Spiral is the opposite of waterfall that people like these days

That process chart has some waterfall in it -- that's clear to see -- but the steps of those waterfalls are often done in a spiral manner (sounds confusing, it really is). So you go down a waterfall in this chart, do some work, but you split the functionality of what you make into "blocks". The first block features the basic functionality. Subsequent blocks build on that.

Really the DoD chart is what the DoD tells itself about how it designs and develops products, but in reality, it's even messier and more confused. It's the world's biggest exemplar of a spaghetti process.

"Really the DoD chart is what the DoD tells itself about how it designs and develops products, but in reality, it's even messier and more confused. It's the world's biggest exemplar of a spaghetti process."

Well put. It's how I've interpreted it from the outside looking at descriptions/slides vs results.

Spiral is waterfall with short iterations and the predecessor to Agile's increments. It's also not how defense procurements usually work. They get a big contract, divide that into different phases, subdivide each phase's work into subcontracts, these might be further subdivided, and there are various points of integration. There are DOD efforts that used Spiral or want to do Agile but the status quo is quite waterfall-like. Even if your small part is Spiral, you might still be forced into an overall water-fall structure.

One of many reasons I stay out of that sector. It can be like working in a straight-jacket sometimes.

Reply on news.ycombinator.com