Re: Ease of product development (was Re: Nanotech arms race worries:all smoke and no fire?)

From: John S. Novak, III (jsn_at_panix.com)
Date: 07/14/04 

Date: 14 Jul 2004 06:13:09 GMT

In article <cd27ns0218l@enews3.newsguy.com>, Chris Phoenix wrote:
 
>>> Furthermore, even when the first MNT assembler or nanofactory arrives on
>>> the scene, the design and development problems do not go away. The
>>> technology will be in virgin territory and there will be teething problems
>>> in the design of products and in each generation of device. Each of these
>>> problems will takes months and possibly even years to work out.
  
>> This is quite, quite true.
 
>> Far too many nanotech enthusiasts, and even a number of self-appointed
>> experts are running around with the notion that once we have
>> nanotechnology, we will automagically solve not only production
>> problems, but design problems as well. .... New
>> technoogies do not "solve" design problems; they render some design
>> problems obsolete, ameliorate others, and introduce still other new
>> design problems.
 
> Levels of abstraction is an extremely powerful design tool.

No kidding. Enough so that, once a level of abstraction is mastered
about a quareter of the way (in the hardware world) another layer is
added.

> Levels of abstraction will be as useful for molecular manufacturing as
> it is for software. Once a function is developed and characterized, it
> will be reusable in many higher-level designs. The "teething problems"
> at the level of molecular machinery will only have to be solved for a
> few basic designs: a motor, a few logic gates, some bearings and other
> simple mechanical components. This will admittedly be hard.
 
I have grave disagreements with this hyper-optimistic assertion of
the future of engineering design. You could say the same thing about,
for instance, monolithic microwave integration circuit techniques, and
it would sound just as good. Yet, astonishingly, monolithic microwave
integration struggles mightily to take any of its basic toolboxes and
put even half a decent receiver (one conversion stage) on one
economic, manufacturable chip.

> But once a set of reusable machines is developed and characterized,
> there'll be no more molecular engineering needed. Just aggregation of
> well-understood systems. Sure, there'll be some unexpected interactions
> that will have to be debugged. But this is the kind of thing embedded
> software engineers do all the time. I know--I was one for six years.

Well of *course* you expect engineering to be like software
engineering, Chris! You're a *software engineer!*

I, however, am a hardware developer. I've been a military electronics
developer for eight years now, after my post-graduate work as an
electrical engineer. I am technical lead on my projects, and I
moonlight as a systems engineer between major project pushes.

In order to do my primary job job effectively, I need to know very
well how to take abstractions from above, in the form of subsystem
requirements, and how to take abstractions from below, in the form of
MMIC and component specifications. I certainly need to know how to
draft specifications from above for when I need MMIC (or other)
components designed custom, and how to respond to impractical
subsystem requirements from above.

So I understand the seduction of abstraction very well. Believe me,
we don't build aircraft by thinking of them as large collections of
*** metal, bolts, resistors and capacitors. They are designed as
hierarchies of systems, which is to say, hierarchies of abstractions.
I understand the power of abstraction, and I also understand, through
a lifetime of personal experience, the limits of abstractions as they
apply to hardware.

Systems abstractions are great, as long as they are applied at the
right intersection of system complexity and subsystem difficulty. If
you push either of those factors too hard, you *must* take it into
account in your system hierarchy, otherwise your systems designs will
tend toward unreliable, unproducible, unworkable. (And if you *do*
take it into account, your system model may just yield the result,
"This design is unreliable, unproducible, unworkable," but at least
you know before hand.)

The industry is littered with the broken shells of men and women who
assumed that all the hard work had already been done and they just
needed to bolt stuff together. They are typically made managers of
departments which employ only themselves.

> My first month on the job, I tracked down a bug in the compiler and two
> in the CPU. With well-specified and simple functionality at each level,
> you can learn and debug at least four to six levels of abstraction--and
> that's enough to build very complex products!

That's not enough to build advanced weapons systems.

I hasten to point out that hardware system debug is a little different
from software system debug.

> Basically, I'm expecting the design of molecular manufacturing products
> to be very similar to the design of software products.

I'm sure you are. I'm not.

All forms of hardware engineering concern themselves with the
arrangement of matter. So will molecular manufacturing. I don't
think it's a stretch to think that, aside from my professional
biases, molecular manufacturing will be considered (will be!) a
hardware engineering discipline, and inherit problems from the
hardware engineering world.

> So much for teething. Now, other design issues: Perhaps the hardest
> thing will be user interface work. (It is in software, too.) Again,
> today's gadgets are generally far simpler than today's software. And
> it'll be possible to build a new gadget for evaluation very quickly and
> cheaply.
 
Define your terms. We started out talking about weapons systems.

> Inter-machine standards will still be a pain: networking protocols,
> physical interconnectivity, cooperative robotics... This is perhaps the
> biggest issue, other than writing levels-of-abstraction CAD software.
 
Chris, if you don't have these problems worked out, then all your
layers of abstraction are useless. You can abstract all you want, but
if you can't hook one abstraction to the other, it's pointless.

> New issue: fault tolerance and recovery. But simple duplication of
> function will work for most applications, adding unnoticeably to the
> cost and bulk and only fractionally to the complexity.

Wow. This is not only a blindly asserted fact not in evidence, it is
actively wrong. This mindset has been actively harmful in my personal
experience.

I recall vividly one NASA project where the systems designers (from
another company) clearly thought this way with regards to a subsystem
they had asked us to build. By the time the specification flowed down
to us, they had added the redundancy to the specifications and
architecture in a way they clearly thought would be semi-cheap, and
not too complex.

And to a degree, they were right. They didn't double the cost or the
complexity or anything. On the other hand, the added redundancy
*broke the whole effing architecture* and ended up requiring a 3dB
sacrifice in at least once system specification. (I suggested telling
them to pick which specification, but I have never been noted for my
diplomacy.)

I will be sure to forward your opinion to the reliability experts I
know, though. They'll be glad to know their work will soon be done.

>> LIkewise, they do not "solve" production problems,
>> they merely shift the economics a bit.
 
> Multiple orders of magnitude is not "a bit." We're talking maybe six
> orders of magnitude in cost-per-feature and cost-per-function, and maybe
> two or three in cost-per-strength.
 
If you're just changing constants, you're just changing constants.
You're a computer scientist. You should know that. 

-- 
John S. Novak, III              jsn@cegt201.bradley.edu
The Humblest Man on the Net
Loading