USAF feels Oleg's pain

[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]

Originally Posted by 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.)

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

[Azimech]

Could you redefine your question please?

[Flying Pencil]

Originally Posted by Azimech

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]

Originally Posted by airmalik

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

(...)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*.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

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, just a random selection amongst many.

Originally Posted by Kyle_W

But software is fractal in complexity.

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

Originally Posted by Kyle_W

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.

Originally Posted by Kyle_W

"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.

Originally Posted by Kyle_W

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]

Originally Posted by Azimech

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]

Originally Posted by Flying Pencil

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]

Originally Posted by swiss

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.