Re: ADC mux charge injection on commercial DAQ boards

In article <fdomqc01oaq@xxxxxxxxxxxxxxxxx>, CC says...
The programmer also stated that for every job he does, his goal is to do
the absolute minimum work to get something working. And if 90% of the
time there aren't problems which come back to him, then he has done too
much. The consequence of this is that the expensive lab time and the
time of scientists get expended in finding and solving problems. But he
takes credit for getting jobs done (which really aren't "done" at all)
very quickly and efficiently.

I have the opposite philosophy. I spend a large amount of time in my
workshop designing things to be nearly perfect before delivery to the
lab, because I believe it is my job to use my time to find and resolve
the problems before installation so that precious lab time isn't wasted.
I have never received a complaint that it took too long, only
compliments that my stuff works perfectly.

This is more than just a design philosophy difference. It's driven by
some fundament real and percieved difference between software and
hardware.

Software is a lot more malleable and flexible (especially over time)
than hardware. As a result software jobs often never finish, there is
always one more small feature to add or a 'simple' way to have the SW
work around a HW limitation. 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. These characteristics of SW specifications make
it a good idea to complete SW that does the most useful and important
fraction of the job and have used before attempting to finish. Often
the rest of the specified functionality is unnecessary or completely
different functionality will be more useful.

This should be a lot less true for a well established product area, but
I would expect it to be true in spades for a laboratory environment.

Now what he does deliver should have the goal of being bug free, but
there are a lot of advantages to delivering short of being functionaly
complete. 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.

Working in hardware you don't have the same luxury of incrementally
adding feature ad-infinitum and you will usually have a more solid
specification to start from.

This difference of view has now led to quite a bitter state of conflict
between us, which is unfortunate. I'm not sure how it will play out. I
am pissed because now I fear this guy has bad-mouthed my work in the
past as taking too long to complete and over-engineered. So he makes
himself look like he's prolific and I'm not. But I'm the one who winds
up with the job to make his partially functional work reach full
functionality. And I get put down for doing it "too well."

That is unfortunate. The forces driving one disciple should not be
imported into another.

I maintain my position that the DT3010-268 is "broken." Would you agree
or disagree?

Sympathise, but disagree.

Should it be the job of the customer of a commercial DAQ
board to have to build analog input buffers on every channel before the
board can be used to specification for any other than "battery" voltage
sources located a few inches from it's inputs?

Their job is to specify what the inputs are including frequency
capability and drive requirements. Yours is to determine how to
translate from your source characteristics to their input
characteristics.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

.

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: something I came to think about ... (logical operators in if statements)
    ... > From my experience with hardware circuit design I'd say that ... > exist many relationships between hardware and software design. ... functionality goes in each. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Detailed article about Mars Rover falure in EE Times
    ... or controversial - perhaps I'm just saying it badly;). ... of functionality, just subtly differently ... I don't concede that the *design* has to be complex, though, at least not ... In hardware terms, discrete components are not hard to ...
    (comp.arch.embedded)
  • Re: Language improvement: Add scope to class member fields
    ... every small subset of functionality into seperate classes. ... MyMethodwould check this flag first within a lock and only run the method ... currently stands there is no protection. ... Allowing classes to become more complex is not a terrific design goal, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: news of the week
    ... And as market leader, that company does not have the time to listen to ... When I designs a website, I constantly have to think about why ... didn't design the website for me. ... offers the same functionality, yet. ...
    (rec.games.computer.ultima.dragons)