How do you know it is right?

Jerry,

The low paid inexperience of 1 and 3b can be very expensive. What about
the time to completion, the quality of the work, and the potential
liability ($$$) of the company?  It is too bad many managers think a)
the hourly rate is what a person costs a company, and b) all engineers
are universally capable of doing a given task.

Dirk


Jerry Avins wrote:
> dbell wrote:
> > Compared to several years ago on comp.dsp I see a huge increase in
> > people asking for help (and code) who don't have a clue what they are
> > doing. If someone gives you code that you don't understand, how do you
> > know if it is right? Do you just believe it? How do you test it? How do
> > you know if your final implementation is working as well as it is
> > supposed to? I have run into DSP code in fielded and about to be
> > fielded systems (including pilot rescue radio and sonar processing
> > system), written by people who didn't know enough about what they were
> > doing to know how to test code that people's lives depended on.  The
> > implementations had major problems with them that would not show up on
> > a test bench at high SNR, but exhibited UNRECOGNIZED impaired
> > performance in the field.
> >
> > comp.dsp is not the first place people should go to solve their
> > problems.
>
> There are categories that look similar.
>
> 1. "My boss said I had to program in speaker recognition. I know diddly
> about DSP. What should I do?" Sometimes this is disguised by a little
> prior research, so that it's sprinkled with buzzwords. It's not too hard
> to see through when those are strung together in a meaningless order.
>
> 2. "I wanna make cool FX. What should I do?" An amateur who thinks that
> such things are easier than they are, but might be up to them with some
> guidance (that he doesn't know enough to ask about specifically).
>
> 3a. A student who just wants to get a grade so he can get a job or
> 3b. one of those students who got a job and now has to deliver.
>
> I fear for the next generation. Be warned: I've been saying that for
> fifty years.
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.
> =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=
=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

dbell wrote:
> Jerry,
> 
> The low paid inexperience of 1 and 3b can be very expensive. What about
> the time to completion, the quality of the work, and the potential
> liability ($$$) of the company?  It is too bad many managers think a)
> the hourly rate is what a person costs a company, and b) all engineers
> are universally capable of doing a given task.

Often, b) boils down to "It's only programming*. It must be trivial."

   ...

Jerry
_______________________________________
* Sometimes it's engineering, not programming. Many suits believe that 
sales is the only industry job that needs expertise.
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Jerry Avins" <jya@ieee.org> wrote in message 
news:c8idnWOwoJpLHJHeRVn-1Q@rcn.net...
> robert bristow-johnson wrote:
>> in article Q3NOe.49462$rp.41853@bignews1.bellsouth.net, Clay S. Turner at
>> Physics@Bellsouth.net wrote on 08/23/2005 18:06:
>>
>>
>>>If you want to read about something really scary about using only 
>>>software.
>>>Read the following account
>>>
>>>http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
>>
>>
>> i remember when that happened.  i remember reading something about it at 
>> the
>> time (i sure thought it was in some IEEE mag) and i think the article was
>> entitled:
>>
>>     "Death by Shared Variable"
>>
>> very memorable title, IMO.
>
> I'm too lazy to read the whole article now. I too remember when it 
> happened, and I learned from it. The problem boiled down to losing sync 
> between the displayed dose and the internally programmed dose because the 
> buggy keypad editing routine changed the first without changing the 
> second. I learned from that

The other important thing was no hardware interlock was used. One was later 
retrofitted, and no more accidents happened. In one of the failure modes, 
the dosimeter would actually saturate and indicate low exposure, so the tech 
would zap the patient again. Some patients were reported to have screamed. 
Not a good sign. By the way Kennestone Hospital is only 15 miles from my 
house.

Clay

"robert bristow-johnson" <rbj@audioimagination.com> wrote in message 
news:BF3206F2.9E68%rbj@audioimagination.com...
> in article c8idnWOwoJpLHJHeRVn-1Q@rcn.net, Jerry Avins at jya@ieee.org wrote
> on 08/24/2005 10:18:
>
>> robert bristow-johnson wrote:
>>> in article Q3NOe.49462$rp.41853@bignews1.bellsouth.net, Clay S. Turner at
>>> Physics@Bellsouth.net wrote on 08/23/2005 18:06:
>>>
>>>
>>>> If you want to read about something really scary about using only software.
>>>> Read the following account
>>>>
>>>> http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html
>>>
>>>
>>> i remember when that happened.  i remember reading something about it at the
>>> time (i sure thought it was in some IEEE mag) and i think the article was
>>> entitled:
>>>
>>> "Death by Shared Variable"
>>>
>>> very memorable title, IMO.
>>
>> I'm too lazy to read the whole article now. I too remember when it
>> happened, and I learned from it. The problem boiled down to losing sync
>> between the displayed dose and the internally programmed dose because
>> the buggy keypad editing routine changed the first without changing the
>> second. I learned from that
>
> i also thought that one of the lessons is that for every editable variable,
> there should be only one method that "owns" it and may write to it.  other
> dudes can read it (and in fact should read it every time it's updated) but
> only one dude may write it.
>
> i thought there was something about that important variable getting written
> over by method #2 and method #1 (just previously having written to that
> variable itself) was oblivious of the change and something bad happened.  i
> dunno.

Using member variables with C++ tends to enforce such rules.  A member variable 
may only be accessed (read or written) by the object where it exists.  You write 
little interface routines so that other objects/code can access the member 
variables.  Of course you can still use global variables if you want to! 

Considering the way in which this thread developed to
discuss fatalities caused by ignorance of computer
programmers, there is a very strong parallel with
those who would be the experts and authorities
in this NG.

Specifically, the sampled signals in our systems are
of the order of volts in height and microseconds in width,
yielding an area of the order of 10^-6.

A large number of people claim that their sampled signals
are represented by Diracian impulses whose area is unity,
a significant engineering mistake. Just where do they
get their figures and their evidence from?

Suppose these people were to go on and provide DSP
within air traffic control or within flight control
systems - a comparable error of 10^-6 means that aircraft
that should be flying at 10,000 metres could be found to
be flying along at 1 cm above the ground.

So much for professionalism, which seems to be lacking
big-time from these self-styled authors and experts.

dbell wrote:
> Compared to several years ago on comp.dsp I see a huge increase in
> people asking for help (and code) who don't have a clue what they are
> doing. If someone gives you code that you don't understand, how do you
> know if it is right? Do you just believe it? How do you test it? How do
> you know if your final implementation is working as well as it is
> supposed to? I have run into DSP code in fielded and about to be
> fielded systems (including pilot rescue radio and sonar processing
> system), written by people who didn't know enough about what they were
> doing to know how to test code that people's lives depended on.  The
> implementations had major problems with them that would not show up on
> a test bench at high SNR, but exhibited UNRECOGNIZED impaired
> performance in the field.
>
> comp.dsp is not the first place people should go to solve their
> problems.
> 
> Comments?
> 
> Dirk

"dbell" <dirkman@erols.com> writes:
> [...]
> Comments?

Thanks for an intriguing question, Dirk. I would think that,
simply speaking, the answer lies in testing. Not just a little
bench testing by the developers, but a focused effort to assemble
multiple groups at multiple levels of use and analysis and in 
multiple contextual scenarios. The "real-world" is the final
judge, not our own internalizations of it. It seems like the
conscionable thing to do.

--Randy

-- 
%  Randy Yates                  % "Watching all the days go by...    
%% Fuquay-Varina, NC            %  Who are you and who am I?"
%%% 919-577-9882                % 'Mission (A World Record)', 
%%%% <yates@ieee.org>           % *A New World Record*, ELO
http://home.earthlink.net/~yatescr

Randy,

My main point is the very noticable increase of people who ask
questions of this group but don't have a clue; those people would not
know how to test their code.  I think this group has moved too far
towards a place for people to find quick solutions they don't
understand.  Nobody benefits from that.  I am not talking about the
questions of those who are starting out (or been at it for ages), have
given something some thought, and have come here to clear something
something up or engage in discussion.  It is the 'pretenders' who want
solutions without learning something that scare me (posts like "Please
send me the code cuz I am in a hurry. Thanks"). They put qualified
people out of work, many will invariably produce substandard work or
fail in their task, and in some applications endanger people with their
solutions. I wish we could filter them out, or force them into the
learning group.

Dirk

Randy Yates wrote:
> "dbell" <dirkman@erols.com> writes:
> > [...]
> > Comments?
>
> Thanks for an intriguing question, Dirk. I would think that,
> simply speaking, the answer lies in testing. Not just a little
> bench testing by the developers, but a focused effort to assemble
> multiple groups at multiple levels of use and analysis and in
> multiple contextual scenarios. The "real-world" is the final
> judge, not our own internalizations of it. It seems like the
> conscionable thing to do.
>
> --Randy
>
> --
> %  Randy Yates                  % "Watching all the days go by...
> %% Fuquay-Varina, NC            %  Who are you and who am I?"
> %%% 919-577-9882                % 'Mission (A World Record)',
> %%%% <yates@ieee.org>           % *A New World Record*, ELO
> http://home.earthlink.net/~yatescr

"dbell" <dirkman@erols.com> writes:

> Randy,
>
> My main point is the very noticable increase of people who ask
> questions of this group but don't have a clue; those people would not
> know how to test their code.  I think this group has moved too far
> towards a place for people to find quick solutions they don't
> understand.  Nobody benefits from that.  I am not talking about the
> questions of those who are starting out (or been at it for ages), have
> given something some thought, and have come here to clear something
> something up or engage in discussion.  It is the 'pretenders' who want
> solutions without learning something that scare me (posts like "Please
> send me the code cuz I am in a hurry. Thanks"). They put qualified
> people out of work, many will invariably produce substandard work or
> fail in their task, and in some applications endanger people with their
> solutions. I wish we could filter them out, or force them into the
> learning group.
>
> Dirk

Ahhh - OK, I see your point now. I have noticed the same thing, and
it does sorta "scare me," but I see this as a self-correcting problem;
those who practice such tactics WILL evenutally produce sub-standard
work (or fail in their task) and their reputation (and thus their
careers) will suffer. 

I would also lay just as much or more blame on the managers and money
hungry entrepeneurs who hire such folks. 

I don't know what you can do to "force" the situation though. It seems
better that we just let them "shoot themselves in the foot."

Actually this notion could be extended into the VERY scary phenomenom
I've noticed whereby the folks in power (the managers, etc.) seem to
be most interested in "image" and not "substance." In the
ever-spiraling greed cycle for power and status, it seems that the
"corporate game" is one whose goal is to "look" the best (put the best
spin on things, etc.) and not "make things work the best with the
given amount of resources." My hope is that such a situation cannot
survive for long since the real bottom-line is how well a corporation
makes money, and such tactics WILL eventually be at odds with this
goal.

In any case, I don't think there will ever be a lack of work for
people like you, Dirk, who are extremely competent and work very hard
at their craft.

--Randy

-- 
%  Randy Yates                  % "The dreamer, the unwoken fool - 
%% Fuquay-Varina, NC            %  in dreams, no pain will kiss the brow..."
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Eldorado Overture', *Eldorado*, ELO
http://home.earthlink.net/~yatescr

Randy,

Almost every commercial job in the DC area in DSP (there was an
abundance) has disappeared (est 95% decrease).  I am assuming they went
overseas to some of the people who I have been speaking about where you
can hire 5 engineers for the price of 1.  I know that these locations
have their fair share of good/great engineers, but the evidence is that
the amount of 'off-shoring' has exceeded these people.  I think we are
seeing managers trying to achieve the appearance of good short-term
performance ($$$) at the cost of long-term performance ($$$ and
success). In the process the good engineers here are shortchanged in
opportunities and compensation. I have a friend who was a high-paid
embedded SW programmer who went to being a security guard and is now a
truck driver.  I am sure that wasn't in his career plan when he became
an engineer.

Dirk

dbell wrote:
> Randy,
> 
> Almost every commercial job in the DC area in DSP (there was an
> abundance) has disappeared (est 95% decrease).  I am assuming they went
> overseas to some of the people who I have been speaking about where you
> can hire 5 engineers for the price of 1.  I know that these locations
> have their fair share of good/great engineers, but the evidence is that
> the amount of 'off-shoring' has exceeded these people.  I think we are
> seeing managers trying to achieve the appearance of good short-term
> performance ($$$) at the cost of long-term performance ($$$ and
> success). In the process the good engineers here are shortchanged in
> opportunities and compensation. I have a friend who was a high-paid
> embedded SW programmer who went to being a security guard and is now a
> truck driver.  I am sure that wasn't in his career plan when he became
> an engineer.

How do you suggest we behave? I would not object to the silent treatment 
of those who are uninformed and want their jobs done for them, if we 
could distinguish them from confused DIYers and students. I know I can't 
do that, but I'm willing to be guided.

Asking for workable code is no more sin than asking for a good circuit. 
Around 1950, I decided that my family's sound system needed upgrading. 
Having made many of my other toys (starting at age 3 with help from my 
father) it seemed reasonable to build it myself. (At the time, I wanted 
to be a chemist.) I listened around and looked over available circuits 
for quality of sound and simplicity of construction, and settled on one 
called an "Ultralinear Williamson", in part because the circuit came 
with the output transformer. My preamp was cobbled together from the 
circuit diagram of a British Leak preamp and power-supply things I was 
beginning to learn. I could not have designed any of that at the time, 
but I could build it. Three years later, I ran the service department in 
a hi-fi boutique, designing special audio equipment not available on the 
  market. Eventually, I got a degree that made it official: I are one.

If you can find a way to distinguish the paid incompetents from people 
like me, I'm with you.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������