Re: Detailed article about Mars Rover falure in EE Times

From: Steve at fivetrees (steve_at_NOSPAMTAfivetrees.com)
Date: 02/27/04 

Date: Fri, 27 Feb 2004 21:19:24 -0000

"John E. Perry" <j.e.perry@larc.nasa.gov> wrote in message
news:c1o48d$ngc$1@news2.news.larc.nasa.gov...
> You can't "design complexity out" without changing the problem. Of
course,
> you can (as others have pointed out) make your solution (_not_ the
problem)
> more complex by inappropriate approaches to your problem's solution.

I fear I've either expressed myself badly, or we're getting into semantics.

I fully agree that a problem has a given complexity. But how that problem is
expressed is extremely subjective. Some people have a knack for making
something simple appear complex, and vice versa. I don't believe I'm saying
anything new, or controversial - perhaps I'm just saying it badly ;).

I'll concede the point with respect to the defined problem. I would nitpick
just a little - I've frequently sat down with customers and focussed them on
requirements, rather than expectations, and simplified the spec with no loss
(frequently even a gain) of functionality, just subtly differently
expressed. Stage #1 of complexity management.

I don't concede that the *design* has to be complex, though, at least not
when well decomposed. In hardware terms, discrete components are not hard to
understand individually. Collectively it needn't get any tougher, depending
on the skill of the designer - and of the person doing the schematic, if not
the same. We've long since developed the art of partitioning to enhance
understanding and hence reliability. Nothing new there. Divide and conquer
etc.

That's really all I'm saying, but applied to software. For me, a "good"
design is one where I can rapidly assimilate the overall functionality of
the thing. Moving on down, each element is clear and well-partitioned. If
the interfaces are "good" (in my terms), I won't find something at the
lowest level that invalidates my high-level understanding. Structured
design, and more latterly OO, have stressed this point. The challenge is to
make this a routine reality - I don't believe we, as an industry, are there
yet. I guess this is why I keep banging on about it.

I said:
>> All problems, hardware or software, tend to be complex until the
complexity is designed out. If it's still complex at the end of the
exercise, then the exercise has failed. <<

I could no doubt have expressed this better, but I do literally mean it -
the ideal (for me) is where complex functionality can be achieved in the
simplest and most comprehensible way. For me, this is the primary objective
of good design. Hardware folks know this, and frequently achieve it.
Software folks (I believe) also know this, or should do, but frequently
(usually?) fail to achieve it. I find this curious.

I note your organisation as NASA at Langley. Ah, a name most familiar from
the several dozen biogs on my bookshelf ;). I quoted Bob Gilruth earlier in
this thread as a staunch defender of the KISS principle - he was a Langley
man, IIRC?

Steve
http://www.fivetrees.com
http://www.sfdesign.co.uk

Relevant Pages

  • Re: ADC mux charge injection on commercial DAQ boards
    ... It's driven by some fundament real and percieved difference between software and hardware. ... In addition because of the perceived simplicity of changing the SW, the specifications for SW are often fuzzy, incompletely thought out and more grandiose than is necessary to do the required job. ... Often the rest of the specified functionality is unnecessary or completely different functionality will be more useful. ... A good design will be done with an eye to exapnding capabilities in the future, an excellent design will succed in having a sufficiently general base that future modifications fit in cleanly, an exceptional design will be so simple and clean that it doesn't require changes since additional functionality can be built out of the existing functionality. ...
    (sci.electronics.design)
  • Re: Security and EOL issues
    ... OS software resources are designed that reserved ram and disk space among other resources, to reflect what current hardware size is available. ... (There was a security patch a few years ago that could not be applied to NT4 as it required more resources then NT4 could provide. ... Installing air bags requires that the automobile manufacturer design, test, ... Computer Emergency Response Teams, and Digital Investigations. ...
    (Security-Basics)
  • Staff HW Engineer ~ Lead Us to ATCA & Beyond in Your End-to-End Board-Level HW Desig
    ... The senior level hardware engineer looking for the product realization ... and true ownership that comes with full end-to-end board-level hardware ... help us retain dominance in the design of high performance switching ...
    (comp.arch.embedded)
  • Re: 10khz DBSK decoder
    ... In an AVR, you may want to come closer to the 'hardwareish' thing: run the whole thing as a Costas loop or as a signal-square-and-PLL, and do integrate-and-dump. ... In retrospect, the ISR should have just taken ADC samples and shoved them into a queue, then set a flag. ... But I had never seen that design pattern, so it just ran with that big bloated ISR... ... You'll get more consistent timing if you can trigger your ADC from hardware and interrupt on the end of conversion pulse. ...
    (comp.dsp)
  • Re: ADC mux charge injection on commercial DAQ boards
    ... This is more than just a design philosophy difference. ... than hardware. ... These characteristics of SW specifications make ... different functionality will be more useful. ...
    (sci.electronics.design)
Loading