Software's evil

True enough.

Sometimes, however, it takes a hero to make a project work but not before he has had the nerve to send away all the nuisance ;)

Reply to
Lanarcam
Loading thread data ...

We have a saying for that: they asked us to make a product that could say "papa-maman" (mum and dad)

Reply to
Lanarcam

It seems to me that the computing used on in the Apollo program was pretty primitive in terms of complexity, performing more of a calculator role than any other. A marvel of complexity to be sure, but more of a mechanical marvel than any other. I think the crew provided much of the processing and IPC :)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
 Click to see the full signature
Reply to
Michael N. Moran

Yes, organizational top to bottom agreement that adherence to a good SW dev process is a prerequisite for success.

If I understand this point, you're saying the hero is advocating for the good SW dev process AND he has the sway or power in the organization to make it happen. Those who advocate but don't have the sway (like me) are walking a fine line between "We need it but nobody's listening" and "I tried, I failed, I'm done". I've drifted from the former to the latter in my growing but software-primitive group, of which is composed of mostly EEs MEs and physicists. I'm not proud of that either :(

(BTW, great thread, close to my heart)

JJS

Reply to
John Speth

If this was true, the phrase "I drive a Pinto" wouldn't get a laugh. The _real_ bottom line is risk. Insurance is one way of managing risk, but nobody carries a policy that will cover the complete loss of a business.

Remember the de Havilland Comet? Remember how difficult it was to get people to board them even once the bugs were fixed?

Reply to
larwe

Yeah, right...

Hopefully most of the bugs were found and corrected or at least noted before the silicon got to you, but the history of known bugs suggests that they are not that uncommon.

I remember reading errata that I found particularly cheeky, the way it was written was that it did not implicate the silicon for the failure of a certain mode of operation, it implicated the documentation for suggesting that the particular mode existed!

And unfortunately, it was that mode that made the chip attractive in the first place.

Reply to
cs_posting

I meant that sometimes you have to tell managers that they are a bunch of ineffective nuisance, (you just don't say it exactly like that), and that if they don't let you manage effectively the project they are in for *the* disaster.

Reply to
Lanarcam

However they are still flying, I believe (or were very recently). They just don't do passenger traffic; they became cargo devices. Their eventual record was very good.

--
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: 
 Click to see the full signature
Reply to
CBFalconer

I have seen both ends of the specification problem.

At the scant end, a specification that left it to the engineer (me) to extract by extensive Q&A exactly what was wanted.

At the enormously complete specification end, it was so complete that all the referenced standards and legislature managed to contradict each other so much that a working solution was impossible to achieve. This specification was reduced from a 900 page document to a mere 35 pages of specification that was entirely adequate following a short Q&A with the client.

You are right, though, in recognising that starting off with a decent specification that has had conflicting requirements resolved, is logically correct and consistent and well structured, will help the progress of a project. Doing more of the thinking (Systems Engineering) work up front saves an enormous amount of time in integration, testing and maintenance.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

...and to finish what I was saying.

Decomposing the requirements specification to the point where recognisable components start to emerge is one of those Systems Engineering tasks that can be helped by the right sort of tools. Tool selection is important whatever the project.

Also important is ensuring that a rigorously applied process is in place where requirements tracked and protected as they are turned into suitably engineered components and thus a suitably engineered system at the end of it. The process should also aid in the provision of an audit trail so that how the process has been managed is very evident throughout the project development lifetime. With some projects the process should continue for the full lifecycle of the project.

If that sounds arduous and far removed from the practices you are currently employing, then you will not be engineering your product.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

It's all a matter of complexity. If you have simple hardware and complex software, you'll have more schedule slips and bugs in the software than in the hardware. But when the hardware becomes as complex as the software, it will have the same sorts of problems.

I've known several engineering managers that thought that if they pushed more of the system functionality into the hardware, it would somehow result in a more reliable product developed in a shorter time.

Reply to
Eric Smith

Huh? I can't even remember the last time I used a microcontroller that had no errata.

Reply to
Eric Smith

It depends also on the organisation or on the culture of the company. Mine is a hardware company and everyone is involved at some stage in the hardware development process, from design to procurement, tests, maintenance, etc. For the software, on the contrary, almost no one is involved apart from the software developers. Of course it's always the software's fault when something goes wrong...

Reply to
Lanarcam

The military variant, Nimrod, is still in use and is expected to be until at least 2020 which would be more than 70 years after the first Comet flight.

Paul

Reply to
Paul Black

"A new car built by my company leaves somewhere traveling at 60 mph. The rear differential locks up. The car crashes and burns with everyone trapped inside. Now, should we initiate a recall? Take the number of vehicles in the field, A, multiply by the probable rate of failure, B, multiply by the average out-of-court settlement, C. A times B times C equals X. If X is less than the cost of a recall, we don't do one."

Fight Club (1999), a very educational movie.

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
Reply to
Boudewijn Dijkstra

I do the hardware and software and find it's always Microsoft's fault when something goes wrong. Even on a small uC based project. :D

--
-Mike
Reply to
Mike Warren

In message , Boudewijn Dijkstra writes

One of the most subversive movies ever. However as I discovered when I saw it at the cinema and listened to the comments of some on the way out: those who could/should have used it as the starting point of the revolution did not understand it.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

One thing that helped: they were dealing with the laws of physics which are pretty stable and well defined. (Heck in 1969 they did most of the calculations on slide rules!) Today's systems have a big issue just dealing with the user interface. And keep in mind the Apollo program did not go flawlessly.

NASA got very good at software development (and systems development), but at a high cost. The developers were HIGHLY motivated. Any mistake could kill astronauts in possibly spectacular ways, and did! Compare that to failure in a parking garage gating system.

There are things they do that should be done in our development. One that I prefer and suggest is using a review technique called Inspections. Code reviews come in several varieties but Inspections can be the most thorough and helpful IMHO. has your company considered review of its processes according to CMM (the Capability Maturity Model)? The scale goes from 1 to 5. NASA was the first (and for a long time the only) level 5. Most companies are level 1: AD HOC. IOW they have no real formal development process. Some companies may not need a formal process. (The one man company that makes parking garage gating systems for example.)

So if you want to improve the development process at your company, you can. But note that even a CMM level 5 organization can fail under pressures of schedule and budget.

Ed

Reply to
Ed Prochak

I agree completely. Our work is primarily safety-critical. For us, the proof is in the process.

Scott

Reply to
Not Really Me

There's a big difference between "Get in that plane, soldier" and "Travel the fast and easy way - individual landings - dropped directly on your destination or points of interest in between - no return fare necessary".

My point was that insurance doesn't mitigate doing something truly asinine in this risk calculation malarkey (like the Ford Pinto business) which could make your products totally unsaleable.

Reply to
larwe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.