USAF feels Oleg's pain

[baronWastelan]

Shot Down By The Hidden Flaw
http://www.strategypage.com/htmw/htecm/articles/20101004.aspx

October 4, 2010: The U.S. Air Force is facing growing problems with software reliability for aircraft. This is largely the result of so much more software being used to operate these airplanes. For example, flight testing of the F-35 was halted on October 1st, so that the software could be fixed. It was believed that a software error was causing fuel pumps to malfunction. The F-35 source code comprises about 8 million lines of code (a file about two gigabytes in size, that could easily fit on a thumb drive). Most modern PC operating systems have source code ten or more times as large, but PC bugs don't cause a $100 million aircraft to crash. Creating flawless software is very difficult, and expensive. It gets more complicated as the amount of software involved increases. This is an aircraft vulnerability that gets little media attention, yet it is very much present, and a growing threat at that.

Then there's the security risks. The contractors who created the F-35 software, did not let the source code anywhere near the Internet, to ensure that Chinese hackers did not grab it. But this software is only valuable if it works. In terms of software, the F-35 is more advanced than the F-22, and has three times as much source code, and even more chances of something going wrong. Source code is the plain text version of the code that is written by programmers, and then turned into the 0s and 1s by a compiler program so that it can operate inside the dozens of microprocessors inside the aircraft.

Software used in combat aircraft has grown enormously over the last two decades. The F-15 appeared in the late 1970s, and had electronics using only a few thousand lines of code. By 1995, upgrades and new equipment had increased this to over 100,000 lines of code. Ten years later the U.S. Air Force began replacing the CPUs (Central Processing Units, the "brains" of a computer) in their F-15E fighter-bombers. The ones being replaced were vintage 1988. Since then, CPUs had become fifty (50) times faster. Since 1995, the CPUs had become even faster.

Naturally, the new CPUs make everything work faster on the F-15E, and allows the aircraft's electronics to do many things it could not do with its original equipment. It's a common problem with warplane electronics, for upgrades to come slowly. It's just not a matter of plugging in a new CPU. Many other new chips are required, and the software has to be rewritten to take advantage of the new capabilities. This takes time, and a lot of money and testing. The air force is reluctant to invest in these upgrades, because money is always tight, and buying new aircraft, or training, often are seen as better investments. The way around this is to build more recent aircraft so that they can be more easily, and cheaply, upgraded with more powerful electronic components. But in the end, if you want better performance these days, you need more software that will take advantage of the new hardware, but it's easier to create reliable hardware, than it is for software.

The older F-15C has also received upgraded electronics, and new software to run it. The add-on equipment, like targeting pods, can easily double the amount of software needed to make the aircraft an effective weapon. But minor flaws in that software can make the aircraft much less deadly, or keep it from even taking off.

I'm guessing that SoW is comparable to the F-35 software in complexity. The sim world is converging with real life aviation.

[Azimech]

For many years I had the idea that aircraft development time increased primarily by the growing need for stable software. Seems I was right.
You see it everywhere in western industry if vehicles are concerned.

Can you believe carmakers wish to delete the physical connections between steer-wheels and pedal-brakes? I'm no luddite, but this goes too far. In a car you don't have the time to switch on a backup like in a plane.

Those enormous amounts of hardware & software aren't exactly in the spirit of Kelly Johnson. Instead of having a few aircraft that are the most complicated and expensive but clearly superior, why not a whole bunch of cheaper and simpler craft to maintain numerical superiority?

Not a single of those jets can fly in space yet the Space Shuttle's software is incredibly tiny in comparison. Instead of all those fancy computerized gizmo's why not develop a plane that can fly to twice the altitude of your competition so you can again dictate any rules of engagement? Think the X15 had a computer on board?

I like computers, that's not it. But I rebuilt my own 25 year old car and thank myself, I can repair it all by myself. The only computers that thing has operate the digital dash and the radio.

[lbuchele]

I recently read something in a Brazilian car magazine about software problems in the Ford Fusion V6 who was leading to the automatic gearbox disengaging suddenly going to neutral.
No big deal, unless you are in the middle of overtaking a car on the road.
Nothing mechanically wrong, just software problem,easily solved with reprogramming,but
it´s scary that this sort of thing can happens in a perfect normal car with no warning...

[WTE_Galway]

Lockheed martin this time huh, surprised it was not Northrop Grumman again. I notice they were in the news again a few weeks back for ripping off the DoD yet again:


The Virginian-Pilot
© September 9, 2010

A Pennsylvania subcontractor has been charged with defrauding the government by supplying critical metal components for submarines that did not meet Navy specifications.

The metal was intended for use in Virginia-class subs, which are built by Northrop Grumman's Newport News shipyard in partnership with Electric Boat of Groton, Conn.

According to papers filed Tuesday by federal prosecutors in Philadelphia, Bristol Alloys and its president, James R. Bullick, fraudulently certified that metals critical to the submarines' integrity had been heat-treated when they had not been.

The Fairless Hills, Pa., company is no longer in business, its attorney, Michael Diamondstein, said Wednesday.

Diamondstein said his client "has cooperated with the United States government in trying to help them locate any of the nonconforming pieces of steel. It's our understanding that at no point in time were members of the United States military in danger due to this."

Spokesmen for the Navy and the U.S. attorney's office in Philadelphia declined to say whether any of the disputed metal has been installed in submarines or whether there are safety implications for the subs and their crews.

A Northrop Grumman spokeswoman said the company is cooperating fully with the government but declined to comment further, citing the pending criminal case.

[bf-110]

I'm guessing that SoW is comparable to the F-35 software in complexity. The sim world is converging with real life aviation.

Nah..It has only a small difference.If something in SoW goes wrong,game crashes.If something goes wrong in a F-35,plane crashes too.

Other day I saw that computer viruses could infect car CPUs.I wonder if one can´t get its way trought a F-22 CPU?

[baronWastelan]

Here's how I see it: the cockpit of a new jet fighter or Airbus is actually a flight simulator, with a real airplane attached to it. So, any problem you might have with your PC could also happen to the CPU on the aircraft. Not very conforting to think about! :o

[AndyJWest]

Other day I saw that computer viruses could infect car CPUs.
Sounds unlikely. Where did you see this?

There are methods for reducing the harmfulness of software errors in safety-critical systems. One is to get code written by three different teams, and use 'majority voting' if there is a conflict when the system is operating. The flaw with this is it assumes that different programming teams won't make the same sort of errors - a doubtful assumption to rely on.

[dduff442]

From Mariner 1 via Ariane 5 to the SAAB Gripen prototype, the history of software in aviation is dismal. If a civil engineer built a bridge that collapsed, he'd be ruined. A software engineer builds his bridge again and again - hundreds of times - and when it finally stands up on its own there's a big party.

Thankfully physical modelling like Il-2/SoW has a better record than most, but many large software projects exhibit not just a lack of competence but a lack of understanding of the most basic precepts of engineering. It's not just that many big IT projects end up non-functional, they start out with designs that couldn't function in the first place. Computer Science grads need to be taught the difference between provable and non-provable designs and how to test ideas.

dduff

[WTE_Galway]

From Mariner 1 via Ariane 5 to the SAAB Gripen prototype, the history of software in aviation is dismal. If a civil engineer built a bridge that collapsed, he'd be ruined. A software engineer builds his bridge again and again - hundreds of times - and when it finally stands up on its own there's a big party.

Thankfully physical modelling like Il-2/SoW has a better record than most, but many large software projects exhibit not just a lack of competence but a lack of understanding of the most basic precepts of engineering. It's not just that many big IT projects end up non-functional, they start out with designs that couldn't function in the first place. Computer Science grads need to be taught the difference between provable and non-provable designs and how to test ideas.

dduff

Unfortunately programmers as a profession are not subject to the industry self regulation and/or government certification that governs the conduct of architects, engineers, lawyers, doctors, surveyors, accountants and other professions.

The software industry is more akin to book or music publishing then any of the more traditional "professions" .

[julian265]

Can you believe carmakers wish to delete the physical connections between steer-wheels and pedal-brakes? I'm no luddite, but this goes too far.

+1 to that. Hydraulic brakes are so simple and reliable... Perhaps a good reason to change it is if you have a completely automated braking system, but my experiences of ABS have been poor, with it degrading braking on surfaces other than smooth bitumen roads. I'll never forget the ~2003 camry that chattered it's way into an (empty) intersection, after we started braking side-by-side coming down a wet road on a slight hill. My '83 car stopped without issue. Traction control is another story of mis-automation. Try a gravel road/driveway on a moderate incline and it struggles.

Unfortunately programmers as a profession are not subject to the industry self regulation and/or government certification that governs the conduct of architects, engineers, lawyers, doctors, surveyors, accountants and other professions.

The software industry is more akin to book or music publishing then any of the more traditional "professions" .

The law makers might actually have to understand the programming process to try to regulate it... Or the government will outsource the writing of the regulations YET AGAIN and force people to PAY to find out what they are required to do. :roll:

Regulations are an interesting topic, I think what prevents a lot of mistakes within engineering are the numbers of people that check the designs, which is often the exact opposite with programming. I don't see a reason to impose regulations on non-safety critical programmers though.

[baronWastelan]

From Mariner 1 via Ariane 5 to the SAAB Gripen prototype, the history of software in aviation is dismal. If a civil engineer built a bridge that collapsed, he'd be ruined. A software engineer builds his bridge again and again - hundreds of times - and when it finally stands up on its own there's a big party.

Thankfully physical modelling like Il-2/SoW has a better record than most, but many large software projects exhibit not just a lack of competence but a lack of understanding of the most basic precepts of engineering. It's not just that many big IT projects end up non-functional, they start out with designs that couldn't function in the first place. Computer Science grads need to be taught the difference between provable and non-provable designs and how to test ideas.

dduff

That's quite funny, but is it a fair comparison? People have been been building bridges for 1000's of years, and they all do practically the same thing. A single piece of software can do 100's of different things, many of them that have never been done before.

[Azimech]

From Mariner 1 via Ariane 5 to the SAAB Gripen prototype, the history of software in aviation is dismal.


I can give you an outstanding exception: the Voyager program.

[dduff442]

I can give you an outstanding exception: the Voyager program.

I wasn't familiar with this at all, but a trip to Wikipedia turned up the following:

Voyager 2's gyroscopes and its computer were operational during its Titan/Centaur launch phase, monitoring the sequence of events, in order for those systems to take over the space probe's attitude control and other functions upon separation from the Centaur upper stage. But at that point, the unexpected happened: Voyager 2's computer experienced robotic "vertigo". In its confusion, it helplessly switched to backup sensors, presuming its "senses" to be defective.

Voyager 2's disoriented flight-control computer remained disconnected from Voyager's powerful thrusters at this point, so it did not cause damage to the launch during the launching itself. The Centaur's attitude-control system stayed in charge, suffering no "vertigo" and, as planned, it electronically corrected the disequilibrium of the Voyager's computer just before separation.

From the spacecraft's control center, engineers and technicians helplessly watched the antics of Voyager 2's disoriented computer. One hour and 11 minutes after lift-off, Voyager 2's own dedicated solid rocket fired for 45 seconds, to supply the final increment of momentum that it needed to get to Jupiter.

I don't mean to knock the potential of software or the talent of its practitioners. What gets me is that the structure of the different markets makes production of quality software uneconomical in many cases.

Put any two software engineers side by side and probably one is a gold mine while the other cancels out his own limited production capacity by pumping garbage into the system. The problem is if you look at their CVs (Resumes), you'll likely never be able to guess which is which.

dduff

[dduff442]

That's quite funny, but is it a fair comparison? People have been been building bridges for 1000's of years, and they all do practically the same thing. A single piece of software can do 100's of different things, many of them that have never been done before.

Mmmm... depends on your definitions of 'do' and 'things'. Modern structures are complex and require careful analysis regarding the transmission of stress to the ground, possible resonance due to wind or earth tremors etc.

The claim that computers do things that have never been done before is dubious... Alan Turing determined universally exactly what computers could do. Other mathematicians determined things that computers could *not* do -- NP complete problems etc. I don't know a massive amount about any of this, but its fair to say that Turing spoke a totally different language to software engineers.

It's reasonable to question the fairness of the jibe I made -- usually nobody need die because a computer programme crashes, unlike with collapsing bridges. Some of the excuses made by the industry don't stand up to criticism, however.

Taking the internet as an example, it was built by electronics and fibre optics specialists and jpeg/mp3 etc (all basically the same tech) made it fast, cheap and economical. Microsoft and Netscape, OTOH, bequeathed us javascript, popups and security holes. Even when I think of the internet myself I think software, but it's an illusion. The hardware basically always works reliably but its invisible. The software types control the branding and somehow come away with all the cash...

dduff

[airmalik]

That's quite funny, but is it a fair comparison? People have been been building bridges for 1000's of years, and they all do practically the same thing. A single piece of software can do 100's of different things, many of them that have never been done before.

I agree. Building bridges can't be compared to building software. This article does a pretty good job of explaining why:

http://gamearchitect.net/Articles/SoftwareIsHard.html

[swiss]

Can you believe carmakers wish to delete the physical connections between steer-wheels and pedal-brakes? I'm no luddite, but this goes too far. In a car you don't have the time to switch on a backup like in a plane.

I thought we are already there. ;)


Not a single of those jets can fly in space yet the Space Shuttle's software is incredibly tiny in comparison. Instead of all those fancy computerized gizmo's why not develop a plane that can fly to twice the altitude of your competition so you can again dictate any rules of engagement? Think the X15 had a computer on board?


The shuttle has ~2million lines.
http://www.nap.edu/openbook.php?record_id=5018&page=10

and:



The book "Code Complete" by Steve McConnell has a brief section about error expectations. He basically says that the range of possibilities can be as follows:

(a) Industry Average: "about 15 - 50 errors per 1000 lines of delivered code." He further says this is usually representative of code that has some level of structured programming behind it, but probably includes a mix of coding techniques.

(b) Microsoft Applications: "about 10 - 20 defects per 1000 lines of code during in-house testing, and 0.5 defect per KLOC (KLOC IS CALLED AS 1000 lines of code) in released product (Moore 1992)." He attributes this to a combination of code-reading techniques and independent testing (discussed further in another chapter of his book).

(c) "Harlan Mills pioneered 'cleanroom development', a technique that has been able to achieve rates as low as 3 defects per 1000 lines of code during in-house testing and 0.1 defect per 1000 lines of code in released product (Cobb and Mills 1990). A few projects - for example, the space-shuttle software - have achieved a level of 0 defects in 500,000 lines of code using a system of format development methods, peer reviews, and statistical testing."

http://amartester.blogspot.com/2007/04/bugs-per-lines-of-code.html


I like computers, that's not it. But I rebuilt my own 25 year old car and thank myself, I can repair it all by myself. The only computers that thing has operate the digital dash and the radio.

I have a 20year old car too, stored for the past 5 years - but last time I checked it was plagued by electronic bugs - not even related to SBEC.

[Azimech]

Interesting read!

[swiss]

+1 to that. Hydraulic brakes are so simple and reliable... Perhaps a good reason to change it is if you have a completely automated braking system, but my experiences of ABS have been poor, with it degrading braking on surfaces other than smooth bitumen roads. I'll never forget the ~2003 camry that chattered it's way into an (empty) intersection, after we started braking side-by-side coming down a wet road on a slight hill. My '83 car stopped without issue. Traction control is another story of mis-automation. Try a gravel road/driveway on a moderate incline and it struggles.


Well, actually ABS decreases braking distance - on any surface other than on dry tarmac.

I remember following experiment, which involved braking in snow, with and without ABS, with and without winter tires.

ABS vs conventional, winter tires:
ABS<conventional

ABS vs conventional, summer tires:
Conventional<ABS

The latter is explained by the conventional wheel locking up, building a wedge of snow in front of the tires which increases friction.
The ABS however is confused, because then summer tires can't get any grip on the snow - and the ABS doesn't want to let them slip, as result the brake stays open...

Is it possible your camry had shitty tires?

[Azimech]

Who knows... it wasn't his Camry.

But anyway, the argument wasn't against ABS, which can be switched off (in the models I drive in, 1 circuit breaker) but the total absence of a hydraulic/mechanical linkage to the pereiopodical appendage (leg). Even a hydraulic system with a leak or a faulty brake vacuum pump will stop your car but if you are pushing the pedal linked to a rheostat while you've lost complete electrical power, maybe smashing your windscreen and blowing in the wind might help (choose your context).

[swiss]

Who knows... it wasn't his Camry.

But anyway, the argument wasn't against ABS, which can be switched off (in the models I drive in, 1 circuit breaker) but the total absence of a hydraulic/mechanical linkage to the pereiopodical appendage (leg). Even a hydraulic system with a leak or a faulty brake vacuum pump will stop your car but if you are pushing the pedal linked to a rheostat while you've lost complete electrical power, maybe smashing your windscreen and blowing in the wind might help (choose your context).

I'm your side here.
But they could design it like pneumatic truckbrakes where your need the air pressure(in our case epower) to keep the brakes open - if their system leaks air, the truck just brakes and stops.

[Azimech]

Keep in mind the pneumatic brake system of a truck is very complex and redundant, with two pressure gauges which a driver is trained to check and act upon. All (competent and awake) drivers will stop the truck before the brakes kick in, at a safe location with opportunity to warn the traffic behind him. I had to learn this stuff.

If a car loses all power and starts braking, it could be at an unsafe spot, without emergency and brake lights. That could lead to utter disaster, especially on a dark, wet road (in a corner, on a downwards slope, etc.)

Even if the system has some kind of a capacitor and warns the driver before the brakes kick in, a lot of people ignore warning lights, interpret them wrong or simply have no clue what it means. My mother is notorious. If I didn't fill up her engine oil every now and then, she called me with the message that a combination of four lights (yes, the Citroën BX does that) came on during corners. Zero oil pressure. I've explained to her a dozen times what it means, that the manual is in the glove compartment, the oil in the trunk and how to fill up the engine. She just doesn't want to remember I guess. Finally I gave up and just bought her a different BX that doesn't use oil at all.

[swiss]

Keep in mind the pneumatic brake system of a truck is very complex and redundant, with two pressure gauges which a driver is trained to check and act upon. All (competent and awake) drivers will stop the truck before the brakes kick in, at a safe location with opportunity to warn the traffic behind him. I had to learn this stuff.

If a car loses all power and starts braking, it could be at an unsafe spot, without emergency and brake lights. That could lead to utter disaster, especially on a dark, wet road (in a corner, on a downwards slope, etc.)

Sure, but have to have a plan. What is it?

[Azimech]

Could you redefine your question please?

[Flying Pencil]

Can you believe carmakers wish to delete the physical connections between steer-wheels and pedal-brakes? I'm no luddite, but this goes too far. In a car you don't have the time to switch on a backup like in a plane.

Those enormous amounts of hardware & software aren't exactly in the spirit of Kelly Johnson. Instead of having a few aircraft that are the most complicated and expensive but clearly superior, why not a whole bunch of cheaper and simpler craft to maintain numerical superiority?

Not a single of those jets can fly in space yet the Space Shuttle's software is incredibly tiny in comparison. Instead of all those fancy computerized gizmo's why not develop a plane that can fly to twice the altitude of your competition so you can again dictate any rules of engagement? Think the X15 had a computer on board?

I like computers, that's not it. But I rebuilt my own 25 year old car and thank myself, I can repair it all by myself. The only computers that thing has operate the digital dash and the radio.

Youd thunk!

Can you image BETA Testing that??
This is Test flight 23b turing to final 27R, lowering gear...
OMG!!! The display has Blue Screen of DeAtH!

Someone some where had a wild idea that instead of a lot of simple, cheap planes, we build a few jack-of-all planes with complex systems.

BTW, depending on when, you have less time to react in an aircraft system failure.

[dduff442]

I agree. Building bridges can't be compared to building software. This article does a pretty good job of explaining why:

http://gamearchitect.net/Articles/SoftwareIsHard.html

I'm sorry -- please don't take it personally but I just had to go nuclear on the article you linked to. It's an admirable lesson in how not to do engineering.

Myst Online started out as a single-player game of modest scope called D'ni In Real Time, or DIRT. By the time I left Cyan, it was planned to be an MMO with a million subscribers, a driving application that would convince casual computer users to sign up for broadband Internet connections. Chandler starts out as a free replacement for Exchange that's simple enough for casual users. But that's not enough. That would be merely ordinary.

The story of Chandler's ensuing development is, for anyone who's spent time developing software, sadly predictable. There comes a point halfway through relating Chandler's saga, where Rosenberg writes, "By now, I know, any software developer reading this volume has likely thrown it across the room in despair, thinking, 'Stop the madness! They're making every mistake in the book!'"

(...)

From the beginning, Chandler is conceived as a peer-to-peer application, for little obvious reason except that P2P apps were considered to be a new and nifty thing at the time the project was starting up.

(...)

((Another problem was)) Uncontrolled feature creep. Kapor originally conceives of Chandler as a complement to Microsoft Outlook targeted at "'information-intensive' individual users and small companies." But everyone on the Chandler team has a different vision of what that means, and in the absence of pressure to ship, Chandler becomes the union of everyone's ideas. Instead of borrowing from successful similar products like Outlook/Exchange, the Chandler team is determined to invent something entirely new from first principles. They want to support user plug-ins and scripting, built-in encryption, storage of messages in multiple folders and infinitely customizable user views. As the project goes on, the simple replacement for Outlook/Exchange grows more and more complicated.

No decision is ever final. Time and again, the Chandler team hashes out compromises on complex issues, only to hit reset when someone new joins the project with new ideas or when it turns out that someone wasn't really satisfied with the compromise. They revisit their choice of database layer, whether to use Mozilla's UI primitives or wxWidgets, and the whole design of their user interface. Eventually, the peer-to-peer architecture is abandoned in favor of a client-server architecture. Three years into the project, the team is still debating whether to turn Chandler into a web-based application like Google Docs & Spreadsheets.

Chandler's story, you'll recall, starts in the spring of 2001. As I write this, in the fall of 2007, OSAF is trying to get version 0.7 of Chandler out the door.

The author has an odd way of making his case -- by showing in fantastic detail how the Chandler team flushed the engineering rulebook down the crapper right from the start. He doesn't describe the complexity of software, he describes the complexity generated by a flock of headless chickens wandering around at random.

And yet, OSAF's employees are all smart people, and most of them have a great depth of experience in software development. How did they end up here?

I actually have no problem believing this. The root of all their difficulties is the fact that their discipline is divorced from all other branches of engineering and science.

A spine of core engineering and science skills should run through the curriculum, even if it was of no *obvious* practical benefit, simply to ground the subject in the broader engineering world and to teach students the commonalities between all its forms.

The examples in the article are classic studies of talent and genuine skill married to a basic lack of competence. Approaches of unnecessary complexity were chosen over simplicity. Approaches that could work on an ad-hoc basis through individual skill but that could never be classified as engineering were preferred to simpler but surefire methods. Peripheral concerns such as the specifics of the UI not only proceeded in parallel with the development of the core system, they were allowed to retroactively redesign it. Use was made of novel or fashionable techniques purely because of their novelty even though they complicated matters, added risk, exceeded the team's expertise and in no way advanced the team towards its goals.

All this by W's own admission and to create... a group scheduling server. This isn't Folding@Home, folks, but an application designed to replace the time-honoured fridge magnet/sheet of paper combo.

(...)All software developers would like to change their minds during the course of development, as they gain knowledge about the application they're making.

If they're working to a formal method -- not always practical, admittedly -- this is possible. More probably, their methods were informal so the moment they start making changes they must either scrap large parts of the design or else their project is *out of control*.

Speaking of lines of code, my friend Rebecca, who's a Pentagon reporter, has sat through countless briefings about military software projects. She's bemused at the briefer's fondness for citing the number of lines of code in the systems they're developing.

This is maybe because the developers are working on a magical "cost plus" Pentagon contract that insures them against any screw ups they make.

The parts that follow this about the difficulties of scheduling are correct, IMO, but much of the problem stems from the proliferation of techniques, languages, philosophies etc. Much of the duplication is pointless and the balkanisation of the industry hinders the development of useful metrics.

In theory, I suppose, the complexity of a well-structured program should be O(n), where n is the number of lines of code, if each line of code is tightly coupled only to the line that precedes it and the line that follows it. A poorly-structured program would be O(n2), with any line of code possibly calling into any other line of code in the program. If n is on the order of a million, the gap between O(n) and O(n2) is staggering. So why do we count lines of code at all? Because it gives us the comforting illusion that we can measure that which is essentially unmeasurable.

The above paragraph is literally gibberish.

When it's done, Fracture ((a game W worked on -- dduff)) will be merely the length of the Encyclopedia Britannica. But it will be a lot more complex.

This is highly implausible and is stated without any evidence or argumentation at all. The complexity of Fracture is mostly trivial and elective. If an encyclopedia can be called simple in any way its because its created according to a proven design and in the simplest way possible.

Every software engineer has a low opinion of the way we develop software. Even the term "software engineering," Rosenberg writes, is a statement of hope, not fact.

I'm with him here. Certain software problems are not amenable to engineering solutions properly speaking. The job mixes art and science. Sadly, most software engineers give little heed to the transition from science to art and needlessly move from the secure outcomes engineering permits to the hocus-pocus of useful but unnecessary methods that can't be proven or kept under control.

And yet, in a typically optimistic programmer triumph of hope over experience, everyone believes that someone, somewhere, is building software the right way, and that we too could make software development predictable and well-behaved if only we possessed sufficient will and discipline.

For 90% of applications, this isn't an aspiration, it's a provable fact.

Part of the problem, clearly, is that every time we build software we're creating something fundamentally new. There are, Wikipedia tells me, six main types of bridges. Once you know how to build a bridge of a particular type, you're just iterating on a theme. The principles behind a suspension bridge, for example, are well understood--if not by me, then at least by the people who build them!

His lack of comprehension of structural engineering doesn't stop him making confident, general statements it. How a group scheduling server constitutes "something fundamentally new" in anyone's mind is beyond me.

Weinberg's Second Law: "If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization." (...) It's true, too, that construction is less predictable than many would like to believe. (...) The difference is that the overruns on a physical construction project are bounded.

Unlike these IT disasters (http://www.infoworld.com/d/security-central/four-infamous-it-meltdowns-404), just a random selection amongst many.

But software is fractal in complexity.

I repeat: he's talking about a system to allow people to arrange meetings over a network.

If you're doing top-down design, you produce a specification that stops at some level of granularity. And you always risk discovering, come implementation time, that the module or class that was the lowest level of your specification hides untold worlds of complexity that will take as much development effort as you'd budgeted for the rest of the project combined.

If unexpected complexity lies within a project description then that description does not satisfy the definition of the word 'specification'. A specification cannot include any component that is not well-defined.

"The complexity of software is an essential property, not an accidental one. Hence, descriptions of a software entity that abstract away its complexity often abstract away its essence."

Try a BS line like that at Siemens or Boeing and security would be escorting you to the door in minutes.

Software construction is the most complex endeavor ever undertaken by mankind. It makes building things like cathedrals and space shuttles look like child's play

The full blush of madness. Countless engineering projects of all sorts involve a software component and all would involve a proper specification -- not a concept W has a good grip on. The software component(s) will have well-defined inputs and outputs and will be mathematically verifiable as possible to execute.

W's argument is totally self-defeating. He starts out by describing a long list of easily avoidable errors, demonstrates a broad ignorance of engineering basics and then explains away disasters in terms of literally meaningless nonsense about complexity dressed up as pseudo-mathematics.

Software needn't be like this. Formal methods won't eliminate bugs but they will enable bugs to be traced. They'll ensure a long lifetime for the codebase and make the project much more cost-effective in the long term. Think Oracle, SAP etc.

Even if the money to fund these methods isn't available, the designer should at a minimum produce a proper specification where each component is theoretically (mathematically) understood.

I don't doubt that either W or Rosenberg are highly talented. Probably they're highly productive as individuals. They're victims of a culture that precludes quality, however, and often guarantees failure.

dduff

[swiss]

Could you redefine your question please?

What's their vision of a fail-safe?

[Azimech]

For the car or the truck? I've updated post #21 with my idea why a failsafe in a car wouldn't always work.

There is an additional problem. If the car brakes are designed to engage when power is lost, you'd need to control that force. If a truck loses all it's air at once, all wheels will stop turning instantly. So when those brakepads start to push the disc, an equal opposite force minus the amount of force for a safe deceleration is needed to prevent locking up. That, is a lot of power and would mean an enormous backup capacitor or a large battery. But since the argument was about the complete loss of power, nothing can be regulated.

This could work however, if all wheels are electrically driven, and the motors work like generators when applying the brake pedal, with a failsafe that the generators would focus a defined amount of their power on a large heatsink for a brisk but controlled deceleration. For a normal application using conventional technology, this is economically unfeasible and very heavy. The force a braking system can develop is more than twice a car engine can produce. For an electric motor to have the same braking ability as a conventional system, you'd have to have a very large, very heavy motor relatively to the rest of the vehicle, so you'd need additional braking capability: disc brakes.

So for the stuff to work safely, you'd have conventional disc brakes with a hydraulic pump and a 4-way computerized brakecommand servo, and 4 generators that pump their power through a relay to a huge heatsink that can absorb the power of a that huge slowing mass.

All that as an alternative to normal operated hydraulic brakes? Call me a luddite.

[Azimech]

Youd thunk!

Can you image BETA Testing that??


Someone some where had a wild idea that instead of a lot of simple, cheap planes, we build a few jack-of-all planes with complex systems.

BTW, depending on when, you have less time to react in an aircraft system failure.

Probably, some idiots in the Air Force have no idea what it all means, and have been brainwashed with marketing slogans from the industry.

You know what Scotty used to say to Kirk? A phrase like "I'll need at least 6 hours to get it working again Cap'n!" Then he did it in 2, and made himself a name as a miracle worker. Who would know, he wrote the book on warp engine dynamics himself.

Now imagine the reverse, the Air Force wants software but the brass doesn't know sh*t about programming. Imagine the amounts of money is made by the industry, and how easy some men can be corrupted. Who can read through all that stuff anyway? It's not like someone can take a ruler to measure dimensions. It's like DNA, we've got a huge amount that is decribed as "junk" and no-one knows what it does. What if programmers have added huge amounts of code that doesn't do anything than point to dev>null and made a few intentional bugs while they where at it?

[julian265]

Well, actually ABS decreases braking distance - on any surface other than on dry tarmac.

I remember following experiment, which involved braking in snow, with and without ABS, with and without winter tires.

ABS vs conventional, winter tires:
ABS<conventional

ABS vs conventional, summer tires:
Conventional<ABS

The latter is explained by the conventional wheel locking up, building a wedge of snow in front of the tires which increases friction.
The ABS however is confused, because then summer tires can't get any grip on the snow - and the ABS doesn't want to let them slip, as result the brake stays open...

Is it possible your camry had shitty tires?

It wasn't mine, I was driving next to it. It was ~3 years old at the time.

I don't claim to know about ABS and snow... I don't drive through any - but my mate's cars with ABS have each become (a little dangerously) confused on loose dirt roads, which we frequent. Hence as Azimech mentioned, they take out the ABS fuse, and regain predictable brakes.