design rigor: electronics vs. software

The company's contributions towards your pension are part of your compensation year by year. Taking that away is no different from trying to claw back 20 years worth of salary.

Cheers

Phil Hobbs

Diane Vaughan's "The Challenger Launch Decision" is an amazingly good read on how they got to that point. She's a sociologist, of course, but she took great pains to understand the culture and the issues, which led her to completely re-evaluate her initial cultural-Marxist take on it.

She has my complete respect for her willingness to follow where the facts led--a rare and valuable trait in our diminished, ideology-driven days.

Cheers

Phil Hobbs

I interviewed with HP once. The guy looked at my resume and said "The first thing you need to do is decide whether you're an engineer or a programmer", so I walked out.

One big company that we work with has, I've heard, 12 levels of engineering management. If an EE group wants a hole drilled in a chassis, the request has to propagate up 5 or six management levels, and then back down, to get to a mechanical engineer. Software is similarly insulated. Any change fires off an enormous volume of paperwork and customer "copy exact" notices, so most things just never get done.

But nobody ever writes a requirement document at the level of detail that the programmers will work to. And few requirement docs are all-correct and all-inclusive.

It sure helps if the programmers understand, and take responsibility for, the actual system.

Is there such a thing? Electronic design is based on physics and corillary principles. I don't know of any hard principles that programming applies. It's more of a craft than a science.

I think that electronics is also easier to design review than software.

Pointers are evil.

Well, don't ignore the warning.

LT4 would complain about, say, one end of a cap floating, or your shorted inductor. The new one doesn't. I prefer it the new way.

I haven't seen the old/new netlist thing that you describe.

e disasters were both hardware problems and both were preventable, but ther e was a clear lack of rigor in the design and execution. The Apollo 13 acc ident was hardware. The list goes on and on.

said the cause of the accident was improperly coded software.

tening to their engineers, including those at Morton-Thiokol, that the boos ter rocket O-Rings were unsafe to launch at cold temperature.

stupid decision to launch under known, unsafe conditions.

I can't believe you are nit-picking this. Even if it isn't your definition of a hardware problem, it certainly isn't a software problem and that was the issue being discussed, software vs. hardware. There's no reason to dis cuss wetware issues other than how they impact software and hardware and in this case it was hardware that failed from the abuse by the wetware.

I guess what I'm really saying is, so what?

ed & Roy Vegas act with the white lions and tigers. They insured against e very conceivable possibility (including the performance animals jumping int o the crowd and causing a panic!). Everything that is, except the tiger v iciously attacking Roy Horn on-stage.

Except that's not what happened. Go read about it. I get tired of educati ng you.

remote the possibility)?

ry flight. Did they never see the tiger?

I think either, you again don't understand what happened, or you have simpl ified your understanding of the accident to "tiles fell off". I'll discuss this further with you if you want, but only after you educate yourself wit h the facts.

Your comments lack nuance.

The definition of "all-correct" can only be made with reference to a Turing machine that implements it.

This, the finished code is the (first and only) finished specification.

Collorary: If a specification is all-correct and all-inclusive, a compiler can be written that implements it precisely.

The trouble is, no-one can tell whether the specification meets the high-level goals of the system - not even the programmer usually.

The reason for "formal methods" is to be able to state the "high level goals" in a precise way, and to show that the code cannot fail to meet those goals.

CH.

What Larkman doesn't understand is that the sort of formal requirements doc uments he is talking about are written for large, complex systems that he k nows literally nothing about. Having never participated in such a design p rocess he doesn't even understand that the programmers can't always know mu ch about the things they are writing code for, because they can't be expert in all parts of the system they are writing code for.

So instead of expecting the coders to sanity check systems they don't and l iterally can't understand, just as no one in the company understands the en tire airplane, they use the documents they are provided to define the softw are they are writing and then test according to the requirements that apply to that software. They don't try to analyze the requirements in the conte xt of the rest of the system because that has already been done.

Larkman also doesn't understand that the requirements documents are written at every level of decomposition so that each requirement can be traced to the modules that are responsible for implementing it. It's a large process , but is essential to making sure the airplane does what you want it to. C an the process fail, yes, it's a human process after all. But it's a whole lot better than the Larkman method of having one guy in charge of everythi ng and he does the hard part for everyone and lets them finish the work tha t he started. I guess we could design bicycles that way, but not airplanes .

I remember dealing with a layout guy who was pretty good, but was used to t hinking in terms of absolute rules without always understanding them. He h ad a big power pour area running across the board to reach a resistor in a part of the circuit that was only to measure the voltage on the power plane . I told him he didn't need to make that run so fat, it could just be a th in trace like any other signal and explained what it was for. He refused t o change it saying that was how you route power planes. Rather than fight that idea, I had him move the resistor to the area of the power plane and r un a thin trace over to the rest of the circuit. He didn't like the idea, but couldn't argue, so did it my way.

This shows why programmers don't get to change low level requirements on th eir own. They either go through the process of pushing back on the high le vel requirements while they are being defined, or they code what needs to b e coded as the requirements state. If the decision makers say the MCAS nee ds to work this way, the coders are not in a position to make changes once the requirements have been decomposed to the module level. It's not like t he people doing the design work didn't give it a lot of thought. Having co ders change the requirements would be like cops changing the laws they have to enforce.

I guess it's a good thing Larkman isn't a cop either.

Sorry, that is simply wrong. You can specify the behavior of a module with out enough detail for a compiler to spit out code unless that compiler had a vast array of tools and libraries at its disposal. So I guess in theory, a compiler could be written, but it would be a ginormous task such as comp iling the English language to computer code.

So, in either case, possible or not, your statement is of no practical valu e.

Huh???

What does that have to do with your compiler statement? First you say spec ifications can't be fully complete and then you say they can be written "in a precise way". Are you say "precise" as in easy to code but not necessar ily complete???

HP hired me because I was both. Various parts of HP were very different from each other.

So you /do/ understand how programmers couldn't be held responsible for implementing the spec.

At HP, if I had been promoted 6 times, I would have been the CEO

Read the C++ FQA

I'm particularly fond of the const correctness section :)

Depends how the development is being done. One way is a formal software specification that is handed to an outsourced team of cheap coders. They literally have no idea what anything does beyond the boundaries of the functional module specification that they have been given to implement.

My boss was pushing for that modus operandi just before I quit.

The idea is that you have well specified software modules in much the same way as IC's that have datasheets describing exactly what they do. It works pretty well for numerical analysis for instance NAGLIB. (way more reliable than rolling your own code)

In in ideal software component model it can work. However, one place I knew referred to their code repository (in jargon term at the time) s/re/su/ Problem was that stuff too often got put into it that was not fit for purpose and would bite anyone foolish enough to reuse it very badly.

Yep. Although it looks like 'warning' should be 'fatal error'. I'm pretty sure LT4 would refuse to run the sim at all with no valid netlist, rather than use the last-known-good one.

Another recent one was a boost switcher. I had that working OK, then added a linear post-regulator, using a model from TI. This added a bunch of extra nodes to the netlist. The TI model turned out to have a typo (the warning said something along the lines of 'diode D_XYZ undefined. Using ideal diode model instead.'

The sim appeared to run OK anyway, but the FET dissipation trace was now multiplying the wrong node voltages/currents (node names from the old netlist) and it was out by an order of magnitude. Once I found the typo and fixed it everything ran fine. I suppose labelling all the nodes would also have caught that one.

I found LT4 more comfortable to use. Still, I can't complain about the price. We have a bunch of PSPICE licenses (came bundled with OrCAD) but LTSPICE is good enough that I've never even tried running it.

^^^^^ This. You fail to understand this. It invalidates the rest of your ignorant complaints.

End. You clearly don't get it, and I'm not going to waste more time on you.

HP's tape drives division was my first 'proper' gig as an EE. They didn't pigeon-hole people either, the hardware guys could write their own test code if needed and the embedded software guys could debug their code using a scope.

Next job was a small startup where everybody had to be a jack-of-all- trades. Later on, as we grew and took on more people, it came as a bit of a shock that the 'straddlers' were a tiny minority. It's something we still struggle with when trying to hire people.

I especially like the way you toss into the conversation totally unsupported statements. I expect you have no real familiarity with the process of developing code using requirements.

I think that would please us both.

You'd be an idiot then.

Literally thousands of projects. Hell I have an archive here of over three hundred projects' documents (several from each project, starting with requirements) on which I participated or led the engineering teams, and those are just from the 1990s (one of my four decades in the software industry).

Much of that code is still running on tens of millions of machines around the globe, coordinating systems management for mission-critical functions in the world's largest enterprises.

Naah, I know nothing about software dev. Nothing you could learn anyhow.