Posted on 04/01/2012 9:20:55 PM PDT by U-238
The Pentagon is focused on resolving complex software issues on the new Lockheed Martin Corp F-35 fighter jet, even as it struggles to drive down costs, a top Pentagon official said on Friday, noting that software failures could "bring us to our knees."
Air Force Major General John Thompson, the No. 2 official in charge of the huge multi-nation warplane development program, said the latest restructuring of the program had given officials enough resources and time to address future challenges.
"Both the hardware and the software issues that we're addressing are all within the realm of being resolved," Thompson told reporters on Friday, noting that Pentagon plans to postpone orders for 179 for five years would allow more time for development before production shifts into high gear in 2019.
He said the F-35 program office, the military services, and Lockheed were working together to reduce costs.
The Pentagon told lawmakers on Thursday that the projected cost to develop, build, operate and maintain the plane for 55 years rose by 8.6 percent to $1.51 trillion from $1.38 trillion in the latest Pentagon estimate.
Thompson said the program was also stepping up work on the 24 million lines of code needed to fly and operate the new warplane and associated ground-based equipment, such as simulators, Thompson said.
"The complexity there gives us pause," he said. "We know we can go fix the mechanical engineering issues associated with structural problems. We're very confident in that. But in terms of fusing together that many lines of code into actual warfighting capability, we realize that could bring us to our knees if it doesn't work."
(Excerpt) Read more at reuters.com ...
See also Sen. Carl Levin on what proportion of military components is sourced from Red China.
Scum members of Congress & Clinton sold us out.
Castration and burning at the stake is too good for some of them...
NO cheers, unfortunately.
ping
We software developers like to think of them as "undocumented features".
But most of the time they are due to a hardware problem....
Ever worked on a software project in the millions of lines of code (mega-LOC)?
I have. cisco’s IOS. Watched it grow from hundreds of thousands to millions of LOC. Last I knew it was over 8 MLOC.
Once you get above the, oh, 500K to 1 MLOC range... most developers simply cannot hold the complexity of the whole system in their heads any more. Out of the entire company’s engineering department, there were only about 12 of us who could hold millions (plural) of LOC complexity in our heads for any length of time. That’s not “memorizing” the code, but simply knowing that “something happens like this over there” in the system map, so that when you make a change “here,” you know you must do something accordingly “over there.”
Most developers tend to lose this ability, and the result is bugs. Some easy to find, some horribly subtle and seemingly random.
Once you get to 10’s of MLOC, you’d better not be using something like C++ or C, because you’ll NEVER, EVER close all the bugs. NEVER. Every C++ system I know of at that size ships with known bugs that they haven’t found yet. Dozens to hundreds of known bugs will be shipped.
The way Boeing got a handle on the situation in the FMS system of the 777 project was to start two competing projects - one in C++ and one in Ada. After awhile, they evaluated which system was closing bugs faster, not writing as many new ones, making deadlines with more certainty. It was the Ada effort. So they closed down the C++ effort and put everything into Ada.
Now, this doesn’t surprise me in the slightest. Ada was created back in the 80’s to enable large s/w systems like these... but the problem is that most of the kids coming out of CS/EE schools today aren’t taught Ada, nor are they taught real-world, “Big System” s/w engineering. They don’t know jack, really. They come out knowing C/C++ and Java... and how to code their silly social media websites... and this corrupts their minds. How you think about large system design is, in part, predicated upon your implementation language.
Anyway, due to lack of newbie engineers trained in something other than C/C++, the F-35 systems are written in C/C++, last I looked. This is one of the reasons why I think we should just kill it now.
C++ in large systems leads to bugs that are hard to replicated, hard to find and a need for lots of static code analysis to try to find the bugs in the source. Seen it many times in industry. C++ is a horrible implementation language unless you literally disable many so-called “features” in the language to preclude them ever being used.
Per my reply to U-238, most large systems will have bugs, regardless of the language in which they’re written.
Most large systems written in C++ will have more bugs.
Once you get beyond trivial systems where you can review all the code and know all the states, transitions and responses to inputs... you’ll have bugs. How many you have is a function of design, implementation language and how willing management is to “do the right thing” instead of meeting their silly schedules.
Now as to back doors, et al... dunno about that, but outsourcing s/w development for anything critical is a Bad Idea[tm]. Especially when the systems become huge.
Most software requires a modicum of correct inputs to produce a modicum of correct results.
Your predicted output results are..........
(ERROR) One
(ERROR) Two
(ERROR) Three
Epic FAIL
While I agree with much of what you say about C++, Java is much better at large systems. The biggest problem is lack of good programmers and changing requirements. Changing requirements is the nature of the beast nothing to be done about that, but most programmers suck, only a few really good ones out there. Sadly the butt kissers and bean counters are the ones in charge so the good programmers rarely get the chance to make a difference.
management is clueless. they think the people that write huge routines with great embedded complexity are the good programmers but the programmers that write small simple routines that can easily be maintained are a dime a dozen.
Maintenance is 80% of the cost of software systems. I can’t tell you how many times I’ve looked at code and said screw this, I am rewriting the entire thing. I would run my code thru a complexity analyzer and rarely got over 20, I’d run code written by the other “top guns” in the company and seldom saw less than 80 sometimes over 200! over 100 was consider unmaintainable due to code complexity. I would beg to be allowed into that code (almost 1 million lines of jdbc) so I could re engineer it. Of course that never happened so I did it on my own time using plain old java objects and hibernate, took me almost two years, I did it just to prove it could be done. I swapped out the entire database layer in a huge enterprise document management system and demo it to management. 1 million lines of complex code to under 100,000 lines of simple code. They were unimpressed. Of course my code had “issues” and did not do all the jdbc code did but the issues could be resolved. A little while later I got canned and software sent to India for maintenance and development. lol, I still have my version running on my computers. Might open source it one of these days.
I started in FORTRAN when memory was NOT cheap, lol. I always liked Cobol, loved C and think Java is pretty cool too. C++ is OK I guess but I’ve never seen a really good reason for using C++ over C or if you need objects over Java. Sometimes I have to talk to the hardware on a PC, so I’ll use a C++ compiler to link with C++ libraries but I still just write in plain old C code.
I think we’re of the same vintage and we agree more than we disagree.
The one central problem I see in many of these huge systems written in C++ is that C++ tries to be all things to every coder, giving tools and paradigms to do literally everything.
When it was just “C with classes” in the late 80’s, it was OK. I have no problem with more modest OOP C implementations, eg, Objective-C and the like, where they try to be more modest and firm in their goals.
But C++? Holy crap. The excuse and reason given by management for not going to Ada-83 in the 80’s was that “Ada is too complex in the wrong areas - we don’t have as much as we need in the area of hardware interface in Ada...”
The excuses I’ve heard for not going to Ada-95, which fixed most of those issues, was that “Ada-95 is too complex.”
Then along comes C++, which is more complex than any other programming language I’ve seen (and I’ve programmed in more than a dozen languages, from assembly to Common Lisp, Smalltalk-80, etc) and management swallows all their Ada excuses and jumps on the bandwagon... because they don’t want to have to train Ada coders in-house.
Morons.
Now, as far as error rates:
The two projects I know of that have error rates one-tenth or lower of the common industry error rates are the Shuttle orbiter and ground system code (not written in C or C++) and the Boeing 777 FMS (written in Ada). The way they both achieved their low error rates was intensive requirements tracking, walk-throughs of design, code walk-throughs, change management, etc. Nothing that wouldn’t work today in any other language.
Trouble is, the C++ shops I’ve seen all leave that behind. They’re all about buying lots of flashing-screen tools and IDE’s, class libraries and pumping out the code.
One of my biggest beefs with C++ is that they mix two huge paradigms into one language: programming by template and programming by classes. I believe that a language should pick on and do it well. Then there’s the lack of native memory management in C++, which I find inexcusable. One of the best reasons I know of to skip C++ and go straight to Java (or similar) languages is that the typical newb programmers are horrid at managing dynamic memory allocation/returns, leading to leaks that remind one of the Titanic.
Google’s Chrome browser and Firefox both have their roots in C++ and they have memory leaks that require I restart them frequently.
Believe me, Newb programmers will find ways to create memory leaks in Java.
Click on pic for past Navair pings. Post or FReepmail me if you wish to be enlisted in or discharged from the Navair Pinglist. The only requirement for inclusion in the Navair Pinglist is an interest in Naval Aviation. This is a medium to low volume pinglist.
don’t = didn’t
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.