1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

How many of your jobs are like this?

Discussion in 'Embedded' started by Mr.CRC, Jun 17, 2011.

  1. Mr.CRC

    Mr.CRC Guest

    Hi:

    I was tasked to create a modern upgrade to the central experiment
    controller for each of 8 multi-million $$$ research laboratories. They
    are still using a DOS based system, except for the first proto that
    we've deployed.

    I get to make the real-time hardware and software, and the programmer
    who worked with the department since the PDP-11 days and developed the
    old system gets to make the PC GUI, which has to be backward compatible
    with old-style text input files.

    The new system has to account for all the lab variations, including one
    with a dual experiment necessitating various multiplexers and
    complications. And add oodles of new capabilities.

    There are no written specs. I poll the scientists to pin down all the
    requirements. In the process I suggest to them what we could do, which
    they want all of and more. I write down most of the requirements and
    set to work. Every once in a while they request new capabilities or
    decide to use higher resolution sensors that the programmer promised we
    would never need, so my design had better incorporate enough headroom to
    be able to adapt without re-spin.

    So over the course of several years, while also being the department's
    Laser Technologist, completing numerous other electronics projects, and
    getting sidetracked by upper management to become an electrical safety
    guy and UL inspect 2000 pieces of equipment--which I finally threatened
    to leave over and they backed down after I got done with about 20:

    I created what I think is an innovative approach to eliminate the old
    practice of custom tweaking the real-time code to implement each variant
    of the experiment and enable the deployment of a flexible yet standard
    solution for all the labs. I chose to implement a dynamically
    reconfigurable state machine which outputs sequenced digital waveforms
    and pulse generator parameters. All glitch-free, and able to be
    reconfigured on the fly while running. Oh, and the state machine
    execution engine meets the real-time deadline of the 4.17us period
    between 240kHz shaft encoder ticks.


    Now that it's done, they don't want to deal with any complexity, don't
    want to read any documentation or learn any new concepts (such as a
    concept that is central to elementary control theory--the state
    machine--and these are all Ph.D. engineers), and the programmer is
    having fits because he doesn't like the state machine control model and
    is 2nd guessing all of my design decisions because the metaphor doesn't
    fit a canonical "programming loop" construct.


    Other than that, it's a great job and they provide me with lots of cool
    equipment and for the most part let me explore many neat new ideas, so
    I'm not complaining. It's just funny (so funny I was up at 3:30am last
    night worrying about it all).


    Let me guess, this is par for the course?


    --
    _____________________
    Mr.CRC

    SuSE 10.3 Linux 2.6.22.17
     
    Mr.CRC, Jun 17, 2011
    #1
    1. Advertising

  2. Mr.CRC wrote:

    > Hi:
    >
    > I was tasked to create a modern upgrade to the central experiment
    > controller for each of 8 multi-million $$$ research laboratories. They
    > are still using a DOS based system, except for the first proto that
    > we've deployed.
    >
    > I get to make the real-time hardware and software, and the programmer
    > who worked with the department since the PDP-11 days and developed the
    > old system gets to make the PC GUI, which has to be backward compatible
    > with old-style text input files.
    >
    > The new system has to account for all the lab variations, including one
    > with a dual experiment necessitating various multiplexers and
    > complications. And add oodles of new capabilities.
    >
    > There are no written specs.


    That is the first big mistake.


    > I poll the scientists to pin down all the
    > requirements. In the process I suggest to them what we could do, which
    > they want all of and more. I write down most of the requirements and
    > set to work.


    Second mistake is not getting the scientists to agree the written
    requirements specification. They should understand that, once written,
    agreed and signed off by them, any changes are going to add cost.

    > Every once in a while they request new capabilities or
    > decide to use higher resolution sensors that the programmer promised we
    > would never need, so my design had better incorporate enough headroom to
    > be able to adapt without re-spin.


    Part of your written specification should be complete interface
    descriptions, including resolution ranges and accuracy of translation.

    > So over the course of several years, while also being the department's
    > Laser Technologist, completing numerous other electronics projects, and
    > getting sidetracked by upper management to become an electrical safety
    > guy and UL inspect 2000 pieces of equipment--which I finally threatened
    > to leave over and they backed down after I got done with about 20:
    >
    > I created what I think is an innovative approach to eliminate the old
    > practice of custom tweaking the real-time code to implement each variant
    > of the experiment and enable the deployment of a flexible yet standard
    > solution for all the labs. I chose to implement a dynamically
    > reconfigurable state machine which outputs sequenced digital waveforms
    > and pulse generator parameters. All glitch-free, and able to be
    > reconfigured on the fly while running. Oh, and the state machine
    > execution engine meets the real-time deadline of the 4.17us period
    > between 240kHz shaft encoder ticks.
    >
    >
    > Now that it's done, they don't want to deal with any complexity, don't
    > want to read any documentation or learn any new concepts (such as a
    > concept that is central to elementary control theory--the state
    > machine--and these are all Ph.D. engineers), and the programmer is
    > having fits because he doesn't like the state machine control model and
    > is 2nd guessing all of my design decisions because the metaphor doesn't
    > fit a canonical "programming loop" construct.
    >
    >
    > Other than that, it's a great job and they provide me with lots of cool
    > equipment and for the most part let me explore many neat new ideas, so
    > I'm not complaining. It's just funny (so funny I was up at 3:30am last
    > night worrying about it all).
    >
    >
    > Let me guess, this is par for the course?


    Not on my watch. It was in my very early days then I learnt the better way
    to organise a project. These days I get to sleep easy at night.

    I can recommend reading "Better Embedded System Software" by Philip Koopman.
    See http://koopman.us/ for details about the book.

    --
    ********************************************************************
    Paul E. Bennett...............<email://>
    Forth based HIDECS Consultancy
    Mob: +44 (0)7811-639972
    Tel: +44 (0)1235-510979
    Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
    ********************************************************************
     
    Paul E. Bennett, Jun 17, 2011
    #2
    1. Advertising

  3. On Fri, 17 Jun 2011 11:28:16 -0700, "Mr.CRC"
    <> wrote:

    >Now that it's done, they don't want to deal with any complexity, don't
    >want to read any documentation or learn any new concepts (such as a
    >concept that is central to elementary control theory--the state
    >machine--and these are all Ph.D. engineers), and the programmer is
    >having fits because he doesn't like the state machine control model and
    >is 2nd guessing all of my design decisions because the metaphor doesn't
    >fit a canonical "programming loop" construct.


    Let me guess ... you've never dealt with users before. Users almost
    never like it when existing processes change and NEVER want to read
    documentation.

    Moreover, if I understood correctly, you've removed some of the
    ability of the users to hack custom applications. That doesn't sit
    well with NIH (not invented here) control freaks. It doesn't matter
    how clever or easy to use your extension method is, they want the
    control that comes from do-it-yourself.

    >Let me guess, this is par for the course?


    Absolutely.

    I used to write industrial QA/QC software that had to have quite
    complex control available to supervisory users while presenting only
    doorknob level controls to ordinary users and requiring in-application
    security to prevent ordinary users from, either inadvertently or
    deliberately, screwing up or breaking anything. [Some of the
    industries served literally used piece-work day laborers who would
    foul up things deliberately to take a break or to bypass QC so as to
    get paid more.] At the same time the functions were getting more
    sophisticated and supervisory control was getting more complex, the
    ordinary user controls had to be secured and idiot proofed, then
    imbecile proofed, and finally moron proofed ... and meanwhile the
    applications had to get smarter and smarter about realizing and
    sounding alarms when the software or hardware was being messed with.

    George
     
    George Neuner, Jun 17, 2011
    #3
  4. Mr.CRC

    Mr.CRC Guest

    Paul E. Bennett wrote:
    > Mr.CRC wrote:
    >> There are no written specs.

    >
    > That is the first big mistake.


    I'm not sure that in the research environment, there is any other
    choice. I mean, I can write some specs for them, such as electrical
    specs. But for behavior, there was no way 5 years ago for us to foresee
    what experiments would need to be done today. They would simply
    complain to the manager that I wasn't serving their needs if I asked
    them to specify anything so precisely. They want me to figure out the
    precise details of what they want, for them.

    >> I poll the scientists to pin down all the
    >> requirements. In the process I suggest to them what we could do, which
    >> they want all of and more. I write down most of the requirements and
    >> set to work.

    >
    > Second mistake is not getting the scientists to agree the written
    > requirements specification. They should understand that, once written,
    > agreed and signed off by them, any changes are going to add cost.


    They don't care about added cost, since the cost of paying me is already
    committed. They only care that when they want it to do something
    different from what they said they wanted it to do last time, that it
    happens as soon as possible.

    >> Every once in a while they request new capabilities or
    >> decide to use higher resolution sensors that the programmer promised we
    >> would never need, so my design had better incorporate enough headroom to
    >> be able to adapt without re-spin.

    >
    > Part of your written specification should be complete interface
    > descriptions, including resolution ranges and accuracy of translation.


    Well the way it actually works is that I ask them what their current
    system does, what they think needs improvement, etc. Then I have to
    become familiar with their work. I have to get in their experiment and
    understand it, get familiar with the direction of their work, then begin
    to make best guesses at what they probably will want to do in the future.

    My experience in this research environment so far is that every time I
    am told to just implement the immediate need, that it is a big mistake
    and it would have been better to spend a little more time to think
    through a more forward reaching solution.

    Every time I think ahead, they wind up actually doing what I thought
    they would do.

    >> Let me guess, this is par for the course?

    >
    > Not on my watch. It was in my very early days then I learnt the better way
    > to organise a project. These days I get to sleep easy at night.


    There is no organizing here. Most of the time, I am it, the only
    electronics person in a department of mechanical engineers. This time I
    have to work closely with the programmer, who originally wanted the
    simplest thing possible, which would have turned out useless the moment
    it was committed to HW.

    > I can recommend reading "Better Embedded System Software" by Philip Koopman.
    > See http://koopman.us/ for details about the book.


    Thanks for the reference and the input.



    --
    _____________________
    Mr.CRC

    SuSE 10.3 Linux 2.6.22.17
     
    Mr.CRC, Jun 17, 2011
    #4
  5. Mr.CRC

    Mr.CRC Guest

    George Neuner wrote:
    > On Fri, 17 Jun 2011 11:28:16 -0700, "Mr.CRC"
    > <> wrote:
    >
    >> Now that it's done, they don't want to deal with any complexity, don't
    >> want to read any documentation or learn any new concepts (such as a
    >> concept that is central to elementary control theory--the state
    >> machine--and these are all Ph.D. engineers), and the programmer is
    >> having fits because he doesn't like the state machine control model and
    >> is 2nd guessing all of my design decisions because the metaphor doesn't
    >> fit a canonical "programming loop" construct.

    >
    > Let me guess ... you've never dealt with users before. Users almost
    > never like it when existing processes change and NEVER want to read
    > documentation.


    Heh heh. And then they will also complain if there isn't detailed
    enough documentation when they get messed up to the point where they
    finally decide to read it.

    I'm more used to giving my users hardware. Software or a system with
    complex user-configurable behavior is a new thing.

    > Moreover, if I understood correctly, you've removed some of the
    > ability of the users to hack custom applications. That doesn't sit
    > well with NIH (not invented here) control freaks. It doesn't matter
    > how clever or easy to use your extension method is, they want the
    > control that comes from do-it-yourself.


    Perhaps you misunderstand a little. The department is quite rightfully
    concerned that when their programmer, who has specialized knowledge of
    engine research and the ability to integrate that into his programming,
    knowledge that is going to be very hard to replace, that they will be in
    a quandry.

    You see it is the programmer, not the scientists, who customizes each
    lab control system to the details of the lab. This is done at the code
    level, not just configuration parameters.

    I have been reading a lot of the technical notes and papers here:

    http://www.stateworks.com

    and some other literature about reconfigurable state machines, and have
    become convinced that it is better to implement flexible system behavior
    by changing configuration information, which instructs an execution
    engine to exhibit the behavior, rather than hard coding the behavior.

    The scientists are not going to be able to customize embedded real time
    code to do what they want once the programmer retires.

    The system that I have designed is capable of exhibiting all of the
    behavior of all the separately customized control systems, and then much
    much more that the current systems cannot do, without any hard coding of
    the behavior. So I have achieved the goal of vastly more capability
    with standardized code for all labs.


    >> Let me guess, this is par for the course?

    >
    > Absolutely.
    >
    > I used to write industrial QA/QC software that had to have quite
    > complex control available to supervisory users while presenting only
    > doorknob level controls to ordinary users and requiring in-application
    > security to prevent ordinary users from, either inadvertently or
    > deliberately, screwing up or breaking anything. [Some of the
    > industries served literally used piece-work day laborers who would
    > foul up things deliberately to take a break or to bypass QC so as to
    > get paid more.] At the same time the functions were getting more
    > sophisticated and supervisory control was getting more complex, the
    > ordinary user controls had to be secured and idiot proofed, then
    > imbecile proofed, and finally moron proofed ... and meanwhile the
    > applications had to get smarter and smarter about realizing and
    > sounding alarms when the software or hardware was being messed with.
    >
    > George


    Interesting experience. Thanks for your response.


    --
    _____________________
    Mr.CRC

    SuSE 10.3 Linux 2.6.22.17
     
    Mr.CRC, Jun 17, 2011
    #5
  6. Mr.CRC

    Don Y Guest

    Hi Paul,

    On 6/17/2011 2:49 PM, Paul E. Bennett wrote:
    > Mr.CRC wrote:


    >> Let me guess, this is par for the course?

    >
    > Not on my watch. It was in my very early days then I learnt the better way
    > to organise a project. These days I get to sleep easy at night.


    <grin> My favorite is when you're trying to nail down a
    spec and grilling the client on what he wants to happen
    in <various_circumstances>.

    Typically, they'll respond with "I don't care..." (i.e.,
    *you* figure it out).

    While taking notes on these exchanges, I have learned how to mumble
    these words (or equivalent) sotto voce:

    "When <various_circumstances>, short out the power supply, spin
    down the drives without retracting the heads, erase all of
    memory..."

    (doing so with a straight face -- "professionally" -- takes *lots*
    of practice! :> )

    The sign of sheer terror on the client's face makes it well worth
    the effort! *And*, they are usually *very* careful not to utter
    the 'I don't care' phrase, again!

    (there *are* some rewards for being in this business!)
     
    Don Y, Jun 17, 2011
    #6
  7. Mr.CRC

    Mr.CRC Guest

    Don Y wrote:
    > <grin> My favorite is when you're trying to nail down a
    > spec and grilling the client on what he wants to happen
    > in <various_circumstances>.
    >
    > Typically, they'll respond with "I don't care..." (i.e.,
    > *you* figure it out).
    >
    > While taking notes on these exchanges, I have learned how to mumble
    > these words (or equivalent) sotto voce:
    >
    > "When <various_circumstances>, short out the power supply, spin
    > down the drives without retracting the heads, erase all of
    > memory..."
    >
    > (doing so with a straight face -- "professionally" -- takes *lots*
    > of practice! :> )
    >
    > The sign of sheer terror on the client's face makes it well worth
    > the effort! *And*, they are usually *very* careful not to utter
    > the 'I don't care' phrase, again!
    >
    > (there *are* some rewards for being in this business!)



    That's very funny! I'll keep that in mind.



    --
    _____________________
    Mr.CRC

    SuSE 10.3 Linux 2.6.22.17
     
    Mr.CRC, Jun 18, 2011
    #7
  8. Mr.CRC

    Joerg Guest

    Don Y wrote:
    > Hi Paul,
    >
    > On 6/17/2011 2:49 PM, Paul E. Bennett wrote:
    >> Mr.CRC wrote:

    >
    >>> Let me guess, this is par for the course?

    >>
    >> Not on my watch. It was in my very early days then I learnt the better
    >> way
    >> to organise a project. These days I get to sleep easy at night.

    >
    > <grin> My favorite is when you're trying to nail down a
    > spec and grilling the client on what he wants to happen
    > in <various_circumstances>.
    >
    > Typically, they'll respond with "I don't care..." (i.e.,
    > *you* figure it out).
    >


    Then I write them out and send it to them.


    > While taking notes on these exchanges, I have learned how to mumble
    > these words (or equivalent) sotto voce:
    >
    > "When <various_circumstances>, short out the power supply, spin
    > down the drives without retracting the heads, erase all of
    > memory..."
    >
    > (doing so with a straight face -- "professionally" -- takes *lots*
    > of practice! :> )
    >
    > The sign of sheer terror on the client's face makes it well worth
    > the effort! *And*, they are usually *very* careful not to utter
    > the 'I don't care' phrase, again!
    >
    > (there *are* some rewards for being in this business!)



    Me, in a board room, nice dark suit and tie (wife picked that out).
    Giving a presentation with lots of big ticket cost factors in there,
    machine amortizations and all that fun stuff. At the end all the other
    suits seemed content with what was presented, the mood became a bit more
    loose, everyone had their thoughts on lunch, the smells of which were
    already wafting in. Then one guy asked "What's your confidence level in
    those numbers?" ... "Ahm, plus minus 3db" ... silence, you could almost
    here a pin drop ... then thundering laughter.

    During lunch the CEO asked me never to pull one like that again, almost
    gave him a cardiac event he said.

    --
    Regards, Joerg

    http://www.analogconsultants.com/

    "gmail" domain blocked because of excessive spam.
    Use another domain or send PM.
     
    Joerg, Jun 18, 2011
    #8
  9. Mr.CRC

    Don Y Guest

    On 6/17/2011 4:41 PM, Mr.CRC wrote:

    >> (doing so with a straight face -- "professionally" -- takes *lots*
    >> of practice! :> )
    >>
    >> The sign of sheer terror on the client's face makes it well worth
    >> the effort! *And*, they are usually *very* careful not to utter
    >> the 'I don't care' phrase, again!
    >>
    >> (there *are* some rewards for being in this business!)

    >
    > That's very funny! I'll keep that in mind.


    **Don't** do it unless you have a really good feel for your
    customer/client!

    With *good* (i.e., "rational") clients, this can lead into
    a sober discussion along the lines of:

    "Well, Bob, how would you like me to go about figuring out
    what *should* be done in these situations? I can take
    the easy way out (for me) -- like 'reset the device and
    start over from scratch'. That will keep your development
    costs down -- anything you can't foresee *here*, *now*
    won't affect the final product's design or its cost.
    OTOH, your users might not like the way the device behaves
    in those cases. Especially if this means they lose 'something'
    (time, data, test results, product, etc.).

    If, OTOOH, you just want me to 'do whatever it takes' to get
    the *right* solution, then your costs (and timetable) become
    unbounded -- but, we can be reasonably assured that the
    end user will be happy with the result.

    Sure, I can *call* you each time I encounter one of these,
    'what-do-you-want-to-do-if' scenarios. But, will you be
    able to give me a quick, well thought-out reply? Who'll
    bear the cost of documenting that? Do I have to update my
    time/cost estimates each time this happens? Who will bear
    the cost of *that*?? Or, do I have to put whatever I was
    working on *aside* and try to *find* something to keep me
    busy (progressing towards a final product) while you think
    about the 'what-if'?

    Lastly, do you think either of us are really going to be
    *happy* working like that?

    So, why don't you guys give this a bit more thought and
    flesh out those areas that you know *I* haven't yet
    discovered (since you guys *should* know more about this
    than me!) and we can look at the project again, later,
    if it still makes sense (you may discover that there is some
    huge GOTCHA that just makes this totally impractical).

    *Or*, you can hire me on an open-ended, time & materials
    basis to research your project, the needs of the targeted
    users, etc. and *write* a specification for you. You can
    then take this and either ask *me* to bid on it. Or, pass
    it around as an RFQ and get someone *else* to bid on it..."

    I.e., this puts the comment into a rational perspective.
    "I'm not trying to be 'cute'... or 'a smart-ass'. This is
    what the consequences of unknowns in your specification
    will be. How would you like to resolve them so we can
    CONTRACTUALLY agree how to proceed?"
     
    Don Y, Jun 18, 2011
    #9
  10. Mr.CRC

    Don Y Guest

    Hi Joerg,

    On 6/17/2011 5:33 PM, Joerg wrote:

    >> <grin> My favorite is when you're trying to nail down a
    >> spec and grilling the client on what he wants to happen
    >> in<various_circumstances>.
    >>
    >> Typically, they'll respond with "I don't care..." (i.e.,
    >> *you* figure it out).

    >
    > Then I write them out and send it to them.


    I'll do that -- *if* they give me a contract to *write*
    that document!

    >> While taking notes on these exchanges, I have learned how to mumble
    >> these words (or equivalent) sotto voce:
    >>
    >> "When<various_circumstances>, short out the power supply, spin
    >> down the drives without retracting the heads, erase all of
    >> memory..."
    >>
    >> (doing so with a straight face -- "professionally" -- takes *lots*
    >> of practice! :> )
    >>
    >> The sign of sheer terror on the client's face makes it well worth
    >> the effort! *And*, they are usually *very* careful not to utter
    >> the 'I don't care' phrase, again!
    >>
    >> (there *are* some rewards for being in this business!)

    >
    > Me, in a board room, nice dark suit and tie (wife picked that out).
    > Giving a presentation with lots of big ticket cost factors in there,
    > machine amortizations and all that fun stuff. At the end all the other
    > suits seemed content with what was presented, the mood became a bit more
    > loose, everyone had their thoughts on lunch, the smells of which were
    > already wafting in. Then one guy asked "What's your confidence level in
    > those numbers?" ... "Ahm, plus minus 3db" ... silence, you could almost
    > here a pin drop ... then thundering laughter.


    "Well, the usual engineering estimates typically require you
    to double the quantity and step up to the next higher unit.
    So, 2 days would become 4 weeks; 3 weeks, 6 months; you get
    the drift...". Let them take the estimate you just gave them
    and go through this little exercise :>

    Again, the key to pulling this off is to maintain a straight
    (poker) face.

    > During lunch the CEO asked me never to pull one like that again, almost
    > gave him a cardiac event he said.


    [<grin> I was bringing up a processor some years ago. Device
    consumed 500W off the -5.2V. I.e., you could put a screwdriver
    across the power rails and the power supply wouldn't *blink*!
    I was plugging in a component with power still on (because cycling
    power was a long, drawn out process). I was in a pretty good mood
    because I was almost done and was 'on a roll'. So, I quipped,
    "Watch me *fry* this sucker!" And, as luck would have it, accidentally
    shorted the ground plane to the power pin *through* the lead of
    the device I was installing. Of course, the lead simply "ceased
    to be" -- accompanied by a nice little "crackle" and flash of
    light! *I* was startled. My boss was *livid* -- "You did that
    INTENTIONALLY!!" <shrug> Some folks just have no sense of humor...]

    Getting back to your meeting...

    Sometimes "comic relief" can help bring about meaningful discussions.
    *Nobody* wants to voice the fears that EVERYONE shares in these
    meetings. And, no one wants to call anyone a liar. But, *everyone*
    knows about 'the best laid plans...'

    If you have people genuinely committed to making a project
    work present, this is a great opportunity for them to be
    candid about their reservations... things you might not have
    seen in the RFQ, things *they* might not realize as consequences
    of some of their requests, etc.

    At the very least, it helps build a rapport between the parties
    so there is less likelihood of folks distancing themselves
    from a failing project, fingerpointing, etc.

    [BTW, decided *not* to get the heavy cream. I figure 3500
    'surplus' calories was a wee bit more than I could afford.
    I'll make gelato, instead -- and only have to exercise *half*
    as much! :-/ ]
     
    Don Y, Jun 18, 2011
    #10
  11. Mr.CRC

    Guest

    On Fri, 17 Jun 2011 22:49:49 +0100, "Paul E. Bennett"
    <> wrote:

    >> Other than that, it's a great job and they provide me with lots of cool
    >> equipment and for the most part let me explore many neat new ideas, so
    >> I'm not complaining. It's just funny (so funny I was up at 3:30am last
    >> night worrying about it all).
    >>
    >>
    >> Let me guess, this is par for the course?

    >
    >Not on my watch. It was in my very early days then I learnt the better way
    >to organise a project. These days I get to sleep easy at night.


    What the OP is doing does not fit any formal definitions of "project".

    Of course, any fixed price contracts are out of the question in this
    kind of environment, but when compensated by the hour, why not.

    In the OP's case, the most important thing is to resist the temptation
    of doing "quick hacks" in order to satisfy some current needs.

    You really have to think ahead and for example provide some primitive
    hooks that could be usable at future request and tell the original
    requestor how to use these hooks e.g. in a configuration file (text)
    to achieve the original requirement.
     
    , Jun 18, 2011
    #11
  12. Mr.CRC

    Bruce Varley Guest

    "Mr.CRC" <> wrote in message
    news:...
    > Paul E. Bennett wrote:
    >> Mr.CRC wrote:
    >>> There are no written specs.

    >>
    >> That is the first big mistake.

    >
    > I'm not sure that in the research environment, there is any other
    > choice. I mean, I can write some specs for them, such as electrical
    > specs. But for behavior, there was no way 5 years ago for us to foresee
    > what experiments would need to be done today. They would simply
    > complain to the manager that I wasn't serving their needs if I asked
    > them to specify anything so precisely. They want me to figure out the
    > precise details of what they want, for them.


    <snip>

    --
    > _____________________
    > Mr.CRC
    >
    > SuSE 10.3 Linux 2.6.22.17


    OK, this is not a trivial situation, it's about *culture*. For starters,
    whatever anyone says, everyone's job contains elements of what you describe.
    During every project small changes will be progressed on the fly, sensible
    implementers will then follow up with an email or something, "confirming our
    discussion of ..., I have ...).

    From what you describe, however, this is a situation which lacks many
    essential controls, and where a lot is happening that shouldn't, and which
    you probably aren't aware of.

    If you really want to attempt to change culture, then I suggest you do a lot
    of reading, and talk to people who are experienced in management, then think
    very hard before you leap in. It's a dangerous game for the inexperienced,
    you could end up badly burnt out, disillusioned and damaged - for life.

    Your alternatives are to play the game and at the same time make small
    changes that you judge you can without upsetting too many stakeholders, or
    to opt out.
     
    Bruce Varley, Jun 18, 2011
    #12
  13. Mr.CRC

    Joerg Guest

    Don Y wrote:
    > Hi Joerg,
    >
    > On 6/17/2011 5:33 PM, Joerg wrote:
    >
    >>> <grin> My favorite is when you're trying to nail down a
    >>> spec and grilling the client on what he wants to happen
    >>> in<various_circumstances>.
    >>>
    >>> Typically, they'll respond with "I don't care..." (i.e.,
    >>> *you* figure it out).

    >>
    >> Then I write them out and send it to them.

    >
    > I'll do that -- *if* they give me a contract to *write*
    > that document!
    >


    Some of that I'll have in the proposal already. So that they know what
    they are going to get and it's not, as Forrest Gump would say, like a
    box of chocolates ;-)

    But that is just a coarse outline. I work by the hour, not per project,
    and sometimes companies want to have a rough overview of how much it'll
    take. For that I need to know the baseline and it must be undestood by
    all involved parties.


    >>> While taking notes on these exchanges, I have learned how to mumble
    >>> these words (or equivalent) sotto voce:
    >>>
    >>> "When<various_circumstances>, short out the power supply, spin
    >>> down the drives without retracting the heads, erase all of
    >>> memory..."
    >>>
    >>> (doing so with a straight face -- "professionally" -- takes *lots*
    >>> of practice! :> )
    >>>
    >>> The sign of sheer terror on the client's face makes it well worth
    >>> the effort! *And*, they are usually *very* careful not to utter
    >>> the 'I don't care' phrase, again!
    >>>
    >>> (there *are* some rewards for being in this business!)

    >>
    >> Me, in a board room, nice dark suit and tie (wife picked that out).
    >> Giving a presentation with lots of big ticket cost factors in there,
    >> machine amortizations and all that fun stuff. At the end all the other
    >> suits seemed content with what was presented, the mood became a bit more
    >> loose, everyone had their thoughts on lunch, the smells of which were
    >> already wafting in. Then one guy asked "What's your confidence level in
    >> those numbers?" ... "Ahm, plus minus 3db" ... silence, you could almost
    >> here a pin drop ... then thundering laughter.

    >
    > "Well, the usual engineering estimates typically require you
    > to double the quantity and step up to the next higher unit.
    > So, 2 days would become 4 weeks; 3 weeks, 6 months; you get
    > the drift...". Let them take the estimate you just gave them
    > and go through this little exercise :>
    >
    > Again, the key to pulling this off is to maintain a straight
    > (poker) face.
    >


    Nope, no with me. My schedules are usually realistic. If a client wants
    to push me towards an unrealistic schedule I politely decline the
    assignment.


    >> During lunch the CEO asked me never to pull one like that again, almost
    >> gave him a cardiac event he said.

    >
    > [<grin> I was bringing up a processor some years ago. Device
    > consumed 500W off the -5.2V. I.e., you could put a screwdriver
    > across the power rails and the power supply wouldn't *blink*!
    > I was plugging in a component with power still on (because cycling
    > power was a long, drawn out process). I was in a pretty good mood
    > because I was almost done and was 'on a roll'. So, I quipped,
    > "Watch me *fry* this sucker!" And, as luck would have it, accidentally
    > shorted the ground plane to the power pin *through* the lead of
    > the device I was installing. Of course, the lead simply "ceased
    > to be" -- accompanied by a nice little "crackle" and flash of
    > light! *I* was startled. My boss was *livid* -- "You did that
    > INTENTIONALLY!!" <shrug> Some folks just have no sense of humor...]
    >


    I've never tried that one :)

    But I did have my power supply comeuppance. Redesigned a large chunk of
    a machine. Fired it up, whirrrrr ... beep .. click ..... whirrrrr ...
    beep .. click. What on earth ..?

    Turns out the power consumption had dropped by so much that we were now
    under the 20% min load of the (now way too big) power supply.


    > Getting back to your meeting...
    >
    > Sometimes "comic relief" can help bring about meaningful discussions.
    > *Nobody* wants to voice the fears that EVERYONE shares in these
    > meetings. And, no one wants to call anyone a liar. But, *everyone*
    > knows about 'the best laid plans...'
    >
    > If you have people genuinely committed to making a project
    > work present, this is a great opportunity for them to be
    > candid about their reservations... things you might not have
    > seen in the RFQ, things *they* might not realize as consequences
    > of some of their requests, etc.
    >
    > At the very least, it helps build a rapport between the parties
    > so there is less likelihood of folks distancing themselves
    > from a failing project, fingerpointing, etc.
    >
    > [BTW, decided *not* to get the heavy cream. I figure 3500
    > 'surplus' calories was a wee bit more than I could afford.
    > I'll make gelato, instead -- and only have to exercise *half*
    > as much! :-/ ]



    I'll have my big peace of Bel Air ice cake tomorrow, as usual. Can't
    wait :)

    --
    Regards, Joerg

    http://www.analogconsultants.com/

    "gmail" domain blocked because of excessive spam.
    Use another domain or send PM.
     
    Joerg, Jun 18, 2011
    #13
  14. Mr.CRC

    Don Y Guest

    Hi Joerg,

    On 6/18/2011 12:59 PM, Joerg wrote:

    >>>> <grin> My favorite is when you're trying to nail down a
    >>>> spec and grilling the client on what he wants to happen
    >>>> in<various_circumstances>.
    >>>>
    >>>> Typically, they'll respond with "I don't care..." (i.e.,
    >>>> *you* figure it out).
    >>>
    >>> Then I write them out and send it to them.

    >>
    >> I'll do that -- *if* they give me a contract to *write*
    >> that document!

    >
    > Some of that I'll have in the proposal already. So that they know what
    > they are going to get and it's not, as Forrest Gump would say, like a
    > box of chocolates ;-)
    >
    > But that is just a coarse outline. I work by the hour, not per project,
    > and sometimes companies want to have a rough overview of how much it'll
    > take. For that I need to know the baseline and it must be undestood by
    > all involved parties.


    I no longer am willing to take on T&M projects. They tend
    to "drag on". Client figures he's paying you so why should
    *you* care how long it takes... (?)

    ("Um, maybe because I think there are other, more interesting,
    things to spend my time on??")

    >>> During lunch the CEO asked me never to pull one like that again, almost
    >>> gave him a cardiac event he said.

    >>
    >> [<grin> I was bringing up a processor some years ago. Device
    >> consumed 500W off the -5.2V. I.e., you could put a screwdriver
    >> across the power rails and the power supply wouldn't *blink*!
    >> I was plugging in a component with power still on (because cycling
    >> power was a long, drawn out process). I was in a pretty good mood
    >> because I was almost done and was 'on a roll'. So, I quipped,
    >> "Watch me *fry* this sucker!" And, as luck would have it, accidentally
    >> shorted the ground plane to the power pin *through* the lead of
    >> the device I was installing. Of course, the lead simply "ceased
    >> to be" -- accompanied by a nice little "crackle" and flash of
    >> light! *I* was startled. My boss was *livid* -- "You did that
    >> INTENTIONALLY!!"<shrug> Some folks just have no sense of humor...]

    >
    > I've never tried that one :)


    To be clear: I did *not* intend for that to happen! It was
    just an unfortunate case of me making a wise crack -- that ended
    up reflecting reality! (bad coincidence)

    > But I did have my power supply comeuppance. Redesigned a large chunk of
    > a machine. Fired it up, whirrrrr ... beep .. click ..... whirrrrr ...
    > beep .. click. What on earth ..?
    >
    > Turns out the power consumption had dropped by so much that we were now
    > under the 20% min load of the (now way too big) power supply.


    Ha! At least you were able to spot the problem (in the load)
    instead of trying to sort out where the design/fab problem lies!

    >> [BTW, decided *not* to get the heavy cream. I figure 3500
    >> 'surplus' calories was a wee bit more than I could afford.
    >> I'll make gelato, instead -- and only have to exercise *half*
    >> as much! :-/ ]

    >
    > I'll have my big peace of Bel Air ice cake tomorrow, as usual. Can't
    > wait :)


    I envy you the fact that you don't have to *make* it in order
    to *enjoy* it! :<

    OTOH, I probably have a wider range of flavoring choices at
    my disposal ;-) I wonder if I can come up with a butter
    pecan gelato that's as flavorful as my butter pecan ice cream?
    (I suspect not as I think much of the "flavor" comes from the
    insane amount of *fat* -- a *stick* of butter in a quart of
    ice cream X-, )

    Today will be a good day for it, too -- uncomfortably hot!
     
    Don Y, Jun 18, 2011
    #14
  15. Mr.CRC

    Joerg Guest

    Don Y wrote:
    > Hi Joerg,
    >
    > On 6/18/2011 12:59 PM, Joerg wrote:
    >
    >>>>> <grin> My favorite is when you're trying to nail down a
    >>>>> spec and grilling the client on what he wants to happen
    >>>>> in<various_circumstances>.
    >>>>>
    >>>>> Typically, they'll respond with "I don't care..." (i.e.,
    >>>>> *you* figure it out).
    >>>>
    >>>> Then I write them out and send it to them.
    >>>
    >>> I'll do that -- *if* they give me a contract to *write*
    >>> that document!

    >>
    >> Some of that I'll have in the proposal already. So that they know what
    >> they are going to get and it's not, as Forrest Gump would say, like a
    >> box of chocolates ;-)
    >>
    >> But that is just a coarse outline. I work by the hour, not per project,
    >> and sometimes companies want to have a rough overview of how much it'll
    >> take. For that I need to know the baseline and it must be undestood by
    >> all involved parties.

    >
    > I no longer am willing to take on T&M projects. ...



    Huh? It's usually the only way I work. Most of my work is on the cutting
    edge so it is next to impossible to do any fixed bid projects. Before
    I'd take on any fixed bid the spec would need to be water-tight and
    complete. Which is not possible in most of my cases.


    > ... They tend
    > to "drag on". Client figures he's paying you so why should
    > *you* care how long it takes... (?)
    >


    Well, they are paying you, right?


    > ("Um, maybe because I think there are other, more interesting,
    > things to spend my time on??")
    >


    There's always more interesting projects or new ones but to me it's a
    matter of loyalty to see the client through to the final goal, even if
    they had a serious schedule slip.


    >>>> During lunch the CEO asked me never to pull one like that again, almost
    >>>> gave him a cardiac event he said.
    >>>
    >>> [<grin> I was bringing up a processor some years ago. Device
    >>> consumed 500W off the -5.2V. I.e., you could put a screwdriver
    >>> across the power rails and the power supply wouldn't *blink*!
    >>> I was plugging in a component with power still on (because cycling
    >>> power was a long, drawn out process). I was in a pretty good mood
    >>> because I was almost done and was 'on a roll'. So, I quipped,
    >>> "Watch me *fry* this sucker!" And, as luck would have it, accidentally
    >>> shorted the ground plane to the power pin *through* the lead of
    >>> the device I was installing. Of course, the lead simply "ceased
    >>> to be" -- accompanied by a nice little "crackle" and flash of
    >>> light! *I* was startled. My boss was *livid* -- "You did that
    >>> INTENTIONALLY!!"<shrug> Some folks just have no sense of humor...]

    >>
    >> I've never tried that one :)

    >
    > To be clear: I did *not* intend for that to happen! It was
    > just an unfortunate case of me making a wise crack -- that ended
    > up reflecting reality! (bad coincidence)
    >
    >> But I did have my power supply comeuppance. Redesigned a large chunk of
    >> a machine. Fired it up, whirrrrr ... beep .. click ..... whirrrrr ...
    >> beep .. click. What on earth ..?
    >>
    >> Turns out the power consumption had dropped by so much that we were now
    >> under the 20% min load of the (now way too big) power supply.

    >
    > Ha! At least you were able to spot the problem (in the load)
    > instead of trying to sort out where the design/fab problem lies!
    >


    The problem was the power supply. They needed a better one. I never
    understood why some switchers have min load requirements. I've designed
    a lot of switchers and none ever had that. You can run them completely open.


    >>> [BTW, decided *not* to get the heavy cream. I figure 3500
    >>> 'surplus' calories was a wee bit more than I could afford.
    >>> I'll make gelato, instead -- and only have to exercise *half*
    >>> as much! :-/ ]

    >>
    >> I'll have my big peace of Bel Air ice cake tomorrow, as usual. Can't
    >> wait :)

    >
    > I envy you the fact that you don't have to *make* it in order
    > to *enjoy* it! :<
    >
    > OTOH, I probably have a wider range of flavoring choices at
    > my disposal ;-) I wonder if I can come up with a butter
    > pecan gelato that's as flavorful as my butter pecan ice cream?
    > (I suspect not as I think much of the "flavor" comes from the
    > insane amount of *fat* -- a *stick* of butter in a quart of
    > ice cream X-, )
    >
    > Today will be a good day for it, too -- uncomfortably hot!



    Our swamp cooler did a wonderful job the last couple of weeks. The only
    thing I don't understand is that while it keeps the temps down it has a
    hard time cooling a house back down if you were gone and it got to 85F.
    I mean, there's 65F coming out at over 3000cfm, meaning it'll
    (theoretically) swap out all the air in the house in 10 minutes. So one
    would think the 85F air will be replaced in a jiffy. But that doesn't
    really happen.

    --
    Regards, Joerg

    http://www.analogconsultants.com/

    "gmail" domain blocked because of excessive spam.
    Use another domain or send PM.
     
    Joerg, Jun 19, 2011
    #15
  16. Mr.CRC

    Don Y Guest

    Hi Joerg,

    On 6/18/2011 4:49 PM, Joerg wrote:
    >> On 6/18/2011 12:59 PM, Joerg wrote:
    >>
    >>>>>> <grin> My favorite is when you're trying to nail down a
    >>>>>> spec and grilling the client on what he wants to happen
    >>>>>> in<various_circumstances>.
    >>>>>>
    >>>>>> Typically, they'll respond with "I don't care..." (i.e.,
    >>>>>> *you* figure it out).
    >>>>>
    >>>>> Then I write them out and send it to them.
    >>>>
    >>>> I'll do that -- *if* they give me a contract to *write*
    >>>> that document!
    >>>
    >>> Some of that I'll have in the proposal already. So that they know what
    >>> they are going to get and it's not, as Forrest Gump would say, like a
    >>> box of chocolates ;-)
    >>>
    >>> But that is just a coarse outline. I work by the hour, not per project,
    >>> and sometimes companies want to have a rough overview of how much it'll
    >>> take. For that I need to know the baseline and it must be undestood by
    >>> all involved parties.

    >>
    >> I no longer am willing to take on T&M projects. ...

    >
    > Huh? It's usually the only way I work. Most of my work is on the cutting
    > edge so it is next to impossible to do any fixed bid projects. Before
    > I'd take on any fixed bid the spec would need to be water-tight and
    > complete. Which is not possible in most of my cases.


    [recall you are working primarily on (analog?) hardware. More and
    more I am moving into pure software designs -- the hardware is
    becoming trivialized (exceptions being power conversion -- which
    I don't mess with :> ) so that part of the design is easy to
    tackle]

    Exactly! People don't want to think about what they want -- they
    want to *see* something... and then decide that that is NOT what
    they want! (OK, let's try something different)

    "User stuff" tends to just drag on and on because people seem
    to lack "imagination". Not "creativity" but, rather, the ability
    to look at a description of how something *might* work, close
    their eyes (figuratively) and *imagine* what it would be like
    to use that hypothetical device... what sorts of problems they
    would likely encounter, how they would work themselves into a
    corner -- and, how they would get back *out* of it, again -- etc.

    [I was discussing one such design with a friend and told her
    exactly what frame of mind she needed to put herself in to
    adequately reflect the needs of the typical user of said device.
    A few days later, she contacted me "all excited". She would
    never have been able to make the connection with the product,
    otherwise!]

    It's easy to get the technology under control. Where things
    tend to get hung up is "humanizing" (userizing?) that technology.

    Now, I try to spend most of my time working on "proof of concept"
    and/or "prototype" designs. Identifying the key issues that
    will ultimately drive the product and seeing how (if?) they work.
    A lot of that happens "between the ears" instead of on paper
    or in foil ("What would likely be the consequence of this type
    of implementation? Where would it fall down? What unexpected
    surprises might come along? Would they be benevolent or
    malevolent? etc.")

    [e.g., this is the force behind the questions like "wire", etc.]

    Or, *if* said device existed and had these particular capabilities,
    what *other* potential applications/markets could it address that
    aren't being addressed (adequately) today?

    So, when I actually have to *make* something, it's only "a handful".
    I don't have to "qualify" components for manufacturing (though I
    have to be able to identify important issues that will ultimately
    affect their selection), I don't have to worry about packaging
    (though I have to have some idea as to the final volume/weight/etc.
    that an implementation is likely to require), regulatory agency
    approvals (except to identify issues that would *necessitate*
    them), etc.

    It's infinitely more "fun" as most of the dreariness has been
    taken out of the process. It's sort of like the OSS guys who
    want to add some zany new feature to a product: do "enough"
    of it to prove it *can* work, then leave the details to others
    to work out. Except, *I* have to take care of those details that
    *make* it work (unlike the OSS guys :< ).

    >> ... They tend
    >> to "drag on". Client figures he's paying you so why should
    >> *you* care how long it takes... (?)

    >
    > Well, they are paying you, right?


    That doesn't mean I want it to last forever! I like moving
    to *different* application domains. You can spend *years*
    tweaking a single product... and its revisions... and its
    successors. You end up being an expert on *that* product
    and little else.

    (could you imagine digging ditches for a living? "for as long
    as your boss wanted ditches dug"? even at your current pay
    scale?? :< )

    >> ("Um, maybe because I think there are other, more interesting,
    >> things to spend my time on??")

    >
    > There's always more interesting projects or new ones but to me it's a
    > matter of loyalty to see the client through to the final goal, even if
    > they had a serious schedule slip.


    As an *employee*, this was no big deal. If the M.E.'s couldn't
    get the mechanism working properly, you were still getting paid.
    Or, if the I.E. didn't have the casing design complete. It was
    your boss' job to figure out how to get suitable work out of you
    given the bottleneck.

    But, on my own, I can't afford to be idled for a month, six weeks,
    etc. if someone has to turn the crank again on some custom silicon.
    And, what if *that* turn goes bad? Or, something else creeps in?
    There's no billable hours there. And, I can't take on another
    contract, in good faith, knowing that 6 weeks hence I will have
    to put *that* on hold.

    It's also very hard to put down a piece of software and come back
    to it months later and know where you were headed. It's not like
    a schematic where you can see *everything* on (dozens?) of pages.
    People forget that you haven't done anything on "their project"
    in "all these weeks" and wonder why you're "so late"...

    >>> But I did have my power supply comeuppance. Redesigned a large chunk of
    >>> a machine. Fired it up, whirrrrr ... beep .. click ..... whirrrrr ...
    >>> beep .. click. What on earth ..?
    >>>
    >>> Turns out the power consumption had dropped by so much that we were now
    >>> under the 20% min load of the (now way too big) power supply.

    >>
    >> Ha! At least you were able to spot the problem (in the load)
    >> instead of trying to sort out where the design/fab problem lies!

    >
    > The problem was the power supply. They needed a better one. I never
    > understood why some switchers have min load requirements. I've designed
    > a lot of switchers and none ever had that. You can run them completely open.


    I think it depends on the design of the switcher logic. I.e.,
    some turn the switching transistor on at each clock edge -- and
    then decide when to turn it *off* based on "current conditions".
    So, the minimum on time of the switching transistor determines
    how much energy you've put into the output stage hoping for a
    load...

    >>>> [BTW, decided *not* to get the heavy cream. I figure 3500
    >>>> 'surplus' calories was a wee bit more than I could afford.
    >>>> I'll make gelato, instead -- and only have to exercise *half*
    >>>> as much! :-/ ]
    >>>
    >>> I'll have my big peace of Bel Air ice cake tomorrow, as usual. Can't
    >>> wait :)

    >>
    >> I envy you the fact that you don't have to *make* it in order
    >> to *enjoy* it! :<
    >>
    >> OTOH, I probably have a wider range of flavoring choices at
    >> my disposal ;-) I wonder if I can come up with a butter
    >> pecan gelato that's as flavorful as my butter pecan ice cream?
    >> (I suspect not as I think much of the "flavor" comes from the
    >> insane amount of *fat* -- a *stick* of butter in a quart of
    >> ice cream X-, )
    >>
    >> Today will be a good day for it, too -- uncomfortably hot!

    >
    > Our swamp cooler did a wonderful job the last couple of weeks. The only
    > thing I don't understand is that while it keeps the temps down it has a
    > hard time cooling a house back down if you were gone and it got to 85F.
    > I mean, there's 65F coming out at over 3000cfm, meaning it'll
    > (theoretically) swap out all the air in the house in 10 minutes. So one
    > would think the 85F air will be replaced in a jiffy. But that doesn't
    > really happen.


    Swamp coolers are BFM. Every time I think I understand how to
    "use" one (control it), I get screwed. One thing that I *have*
    learned is that once the indoor temperature starts creeping up,
    there's nothing you can do to stop it.

    I suspect there must be a science behind "optimal control",
    there. E.g., how much to vent to the outside for a given
    current operating rate, outdoor wind speed/direction, etc.
    It would be fun to motorize the window and let a machine
    "learn" how to do this...

    I think I am going to explore the possibility of replacing the
    fan (squirrel cage) in the cooler with something that works
    effectively in both directions -- turn the cooler into an
    exhaust fan for use at night/early morning.
     
    Don Y, Jun 19, 2011
    #16
  17. Mr.CRC

    Joerg Guest

    Don Y wrote:
    > Hi Joerg,
    >
    > On 6/18/2011 4:49 PM, Joerg wrote:
    >>> On 6/18/2011 12:59 PM, Joerg wrote:
    >>>
    >>>>>>> <grin> My favorite is when you're trying to nail down a
    >>>>>>> spec and grilling the client on what he wants to happen
    >>>>>>> in<various_circumstances>.
    >>>>>>>
    >>>>>>> Typically, they'll respond with "I don't care..." (i.e.,
    >>>>>>> *you* figure it out).
    >>>>>>
    >>>>>> Then I write them out and send it to them.
    >>>>>
    >>>>> I'll do that -- *if* they give me a contract to *write*
    >>>>> that document!
    >>>>
    >>>> Some of that I'll have in the proposal already. So that they know what
    >>>> they are going to get and it's not, as Forrest Gump would say, like a
    >>>> box of chocolates ;-)
    >>>>
    >>>> But that is just a coarse outline. I work by the hour, not per project,
    >>>> and sometimes companies want to have a rough overview of how much it'll
    >>>> take. For that I need to know the baseline and it must be undestood by
    >>>> all involved parties.
    >>>
    >>> I no longer am willing to take on T&M projects. ...

    >>
    >> Huh? It's usually the only way I work. Most of my work is on the cutting
    >> edge so it is next to impossible to do any fixed bid projects. Before
    >> I'd take on any fixed bid the spec would need to be water-tight and
    >> complete. Which is not possible in most of my cases.

    >
    > [recall you are working primarily on (analog?) hardware. More and
    > more I am moving into pure software designs -- the hardware is
    > becoming trivialized (exceptions being power conversion -- which
    > I don't mess with :> ) so that part of the design is easy to
    > tackle]
    >


    The minute you deal with hi-rel, aerospace, medical, EMC and all that,
    hardware is immediately "untrivialized" :)

    [...]


    >>> ... They tend
    >>> to "drag on". Client figures he's paying you so why should
    >>> *you* care how long it takes... (?)

    >>
    >> Well, they are paying you, right?

    >
    > That doesn't mean I want it to last forever! I like moving
    > to *different* application domains. You can spend *years*
    > tweaking a single product... and its revisions... and its
    > successors. You end up being an expert on *that* product
    > and little else.
    >
    > (could you imagine digging ditches for a living? "for as long
    > as your boss wanted ditches dug"? even at your current pay
    > scale?? :< )
    >


    Yep. I'd get myself the coolest Caterpillar there is, with sound-proof
    cabin, six-speaker stereo, the whole nine yards :)

    But it ain't going to happen. Hardware design is a very diverse job.
    Megawatt power designs one day, microvolt receiver design the next.


    >>> ("Um, maybe because I think there are other, more interesting,
    >>> things to spend my time on??")

    >>
    >> There's always more interesting projects or new ones but to me it's a
    >> matter of loyalty to see the client through to the final goal, even if
    >> they had a serious schedule slip.

    >
    > As an *employee*, this was no big deal. If the M.E.'s couldn't
    > get the mechanism working properly, you were still getting paid.
    > Or, if the I.E. didn't have the casing design complete. It was
    > your boss' job to figure out how to get suitable work out of you
    > given the bottleneck.
    >
    > But, on my own, I can't afford to be idled for a month, six weeks,
    > etc. if someone has to turn the crank again on some custom silicon.
    > And, what if *that* turn goes bad? Or, something else creeps in?
    > There's no billable hours there. And, I can't take on another
    > contract, in good faith, knowing that 6 weeks hence I will have
    > to put *that* on hold.
    >


    I always have several assignments concurrently. Some urgent, some not so
    much. It's like with doctors, usually you only need them when sick and
    the workload you present is unpredictable to them unless you have some
    sort of chronic illness.

    Working for just one client is risky. What if they go belly-up?


    > It's also very hard to put down a piece of software and come back
    > to it months later and know where you were headed. It's not like
    > a schematic where you can see *everything* on (dozens?) of pages.
    > People forget that you haven't done anything on "their project"
    > in "all these weeks" and wonder why you're "so late"...
    >


    That's why I keep harping on documentation. Some SW guys think that a
    few comments in the code is sufficient documentation. It ain't. For
    anything I ever designed there is a module spec, whether the client
    wanted it or not. I can't work any other way, or won't. This allows me
    to hop back into the same saddle 10 years late.


    >>>> But I did have my power supply comeuppance. Redesigned a large chunk of
    >>>> a machine. Fired it up, whirrrrr ... beep .. click ..... whirrrrr ...
    >>>> beep .. click. What on earth ..?
    >>>>
    >>>> Turns out the power consumption had dropped by so much that we were now
    >>>> under the 20% min load of the (now way too big) power supply.
    >>>
    >>> Ha! At least you were able to spot the problem (in the load)
    >>> instead of trying to sort out where the design/fab problem lies!

    >>
    >> The problem was the power supply. They needed a better one. I never
    >> understood why some switchers have min load requirements. I've designed
    >> a lot of switchers and none ever had that. You can run them completely
    >> open.

    >
    > I think it depends on the design of the switcher logic. I.e.,
    > some turn the switching transistor on at each clock edge -- and
    > then decide when to turn it *off* based on "current conditions".
    > So, the minimum on time of the switching transistor determines
    > how much energy you've put into the output stage hoping for a
    > load...
    >


    I consider that an unsafe design :)


    >>>>> [BTW, decided *not* to get the heavy cream. I figure 3500
    >>>>> 'surplus' calories was a wee bit more than I could afford.
    >>>>> I'll make gelato, instead -- and only have to exercise *half*
    >>>>> as much! :-/ ]
    >>>>
    >>>> I'll have my big peace of Bel Air ice cake tomorrow, as usual. Can't
    >>>> wait :)
    >>>
    >>> I envy you the fact that you don't have to *make* it in order
    >>> to *enjoy* it! :<
    >>>
    >>> OTOH, I probably have a wider range of flavoring choices at
    >>> my disposal ;-) I wonder if I can come up with a butter
    >>> pecan gelato that's as flavorful as my butter pecan ice cream?
    >>> (I suspect not as I think much of the "flavor" comes from the
    >>> insane amount of *fat* -- a *stick* of butter in a quart of
    >>> ice cream X-, )
    >>>
    >>> Today will be a good day for it, too -- uncomfortably hot!

    >>
    >> Our swamp cooler did a wonderful job the last couple of weeks. The only
    >> thing I don't understand is that while it keeps the temps down it has a
    >> hard time cooling a house back down if you were gone and it got to 85F.
    >> I mean, there's 65F coming out at over 3000cfm, meaning it'll
    >> (theoretically) swap out all the air in the house in 10 minutes. So one
    >> would think the 85F air will be replaced in a jiffy. But that doesn't
    >> really happen.

    >
    > Swamp coolers are BFM. Every time I think I understand how to
    > "use" one (control it), I get screwed. One thing that I *have*
    > learned is that once the indoor temperature starts creeping up,
    > there's nothing you can do to stop it.
    >


    That's the weird thing. You can stop it from creeping up or at least
    slow its rise, but you can baerly make it get down again. In the
    evenings we can, but even then very slowly.


    > I suspect there must be a science behind "optimal control",
    > there. E.g., how much to vent to the outside for a given
    > current operating rate, outdoor wind speed/direction, etc.
    > It would be fun to motorize the window and let a machine
    > "learn" how to do this...
    >


    I've tried experimenting with that. No luck. There comes a point where
    the moisture in the house starts to rise when you close the windows too
    much. But beyond that the cooling efficiency seems to be about the same.


    > I think I am going to explore the possibility of replacing the
    > fan (squirrel cage) in the cooler with something that works
    > effectively in both directions -- turn the cooler into an
    > exhaust fan for use at night/early morning.



    Exhaust would turn it into a whole house fan. I wouldn't want that
    around here because it'll suck in all the pollen and dust. My wife would
    have a fit.

    --
    Regards, Joerg

    http://www.analogconsultants.com/

    "gmail" domain blocked because of excessive spam.
    Use another domain or send PM.
     
    Joerg, Jun 19, 2011
    #17
  18. Mr.CRC

    Don Y Guest

    Hi Joerg,

    On 6/19/2011 10:08 AM, Joerg wrote:

    >>>> I no longer am willing to take on T&M projects. ...
    >>>
    >>> Huh? It's usually the only way I work. Most of my work is on the cutting
    >>> edge so it is next to impossible to do any fixed bid projects. Before
    >>> I'd take on any fixed bid the spec would need to be water-tight and
    >>> complete. Which is not possible in most of my cases.

    >>
    >> [recall you are working primarily on (analog?) hardware. More and
    >> more I am moving into pure software designs -- the hardware is
    >> becoming trivialized (exceptions being power conversion -- which
    >> I don't mess with :> ) so that part of the design is easy to
    >> tackle]

    >
    > The minute you deal with hi-rel, aerospace, medical, EMC and all that,
    > hardware is immediately "untrivialized" :)


    Yeah, but I've been steadily headed *away* from that sort of
    market. And, most of my designs are approaching 100% digital
    (with the exception of power). Even the analog subsystems
    are getting to be "prepackaged".

    >>>> ... They tend
    >>>> to "drag on". Client figures he's paying you so why should
    >>>> *you* care how long it takes... (?)
    >>>
    >>> Well, they are paying you, right?

    >>
    >> That doesn't mean I want it to last forever! I like moving
    >> to *different* application domains. You can spend *years*
    >> tweaking a single product... and its revisions... and its
    >> successors. You end up being an expert on *that* product
    >> and little else.
    >>
    >> (could you imagine digging ditches for a living? "for as long
    >> as your boss wanted ditches dug"? even at your current pay
    >> scale?? :< )

    >
    > Yep. I'd get myself the coolest Caterpillar there is, with sound-proof
    > cabin, six-speaker stereo, the whole nine yards :)


    I'd enjoy playing with the cat' for a few days. Then would
    quickly grow bored with the job. Too repetitive. What do you
    *learn* each day (besides "if it looks like a buried pipeline,
    it probably *is* a buried pipeline!!)

    > But it ain't going to happen. Hardware design is a very diverse job.
    > Megawatt power designs one day, microvolt receiver design the next.
    >
    >>>> ("Um, maybe because I think there are other, more interesting,
    >>>> things to spend my time on??")
    >>>
    >>> There's always more interesting projects or new ones but to me it's a
    >>> matter of loyalty to see the client through to the final goal, even if
    >>> they had a serious schedule slip.

    >>
    >> As an *employee*, this was no big deal. If the M.E.'s couldn't
    >> get the mechanism working properly, you were still getting paid.
    >> Or, if the I.E. didn't have the casing design complete. It was
    >> your boss' job to figure out how to get suitable work out of you
    >> given the bottleneck.
    >>
    >> But, on my own, I can't afford to be idled for a month, six weeks,
    >> etc. if someone has to turn the crank again on some custom silicon.
    >> And, what if *that* turn goes bad? Or, something else creeps in?
    >> There's no billable hours there. And, I can't take on another
    >> contract, in good faith, knowing that 6 weeks hence I will have
    >> to put *that* on hold.

    >
    > I always have several assignments concurrently. Some urgent, some not so
    > much. It's like with doctors, usually you only need them when sick and
    > the workload you present is unpredictable to them unless you have some
    > sort of chronic illness.
    >
    > Working for just one client is risky. What if they go belly-up?


    I'm not talking about hitching your cart to a single client.
    But, the costs of moving between projects aren't small. And,
    *you* bear those costs (how are you going to conscientiously
    bill your clients for your inefficiencies at juggling two or
    more concurrently?)

    A (typical) doctor can move between patients in 15 minute intervals.
    There isn't much *immediate* follow through -- "Go try this and
    let me know what happens". Imagine a surgeon leaving a surgery
    partially completed because some bit of kit wasn't available at
    the time... wandering into the *next* surgery, starting on that
    one, then wandering back to the first one when the necessary
    items became available. :-/

    >> It's also very hard to put down a piece of software and come back
    >> to it months later and know where you were headed. It's not like
    >> a schematic where you can see *everything* on (dozens?) of pages.
    >> People forget that you haven't done anything on "their project"
    >> in "all these weeks" and wonder why you're "so late"...

    >
    > That's why I keep harping on documentation. Some SW guys think that a
    > few comments in the code is sufficient documentation. It ain't. For


    You're preaching to the choir, here!

    > anything I ever designed there is a module spec, whether the client
    > wanted it or not. I can't work any other way, or won't. This allows me
    > to hop back into the same saddle 10 years late.


    But there is a big difference between the effort required to
    prepare a good software specification -- let alone the formal
    *documentation* -- and a similar one for a piece of hardware.
    E.g., I have 100 page documents just describing the *accounting*
    (money) subsystem in gaming devices -- without even mentioning
    how the "game" works!

    By contrast, when documenting hardware, I get a big headstart
    just by preserving copies of all the datasheets used in the
    design (you typically don't have similar documents for the
    software "components" used in a software design -- unless you
    want to consider the language manual and processor instruction
    set as "components"... pretty crude).

    The software industry is lacking a *good* tool to make software
    documentation easier, more complete and more *accurate*. There's
    no "pictorial shorthand" like schematics, timing diagrams, 'scope
    traces, etc. Too much relies on words. Words take a long time
    (relatively speaking) to parse. And, require a lot of effort to
    verify.

    And, since software is so (relatively) easy to change, it becomes
    a cat-and-mouse game where the documentation is always struggling
    to keep up with the latest (ahem) "enhancements".

    >>> The problem was the power supply. They needed a better one. I never
    >>> understood why some switchers have min load requirements. I've designed
    >>> a lot of switchers and none ever had that. You can run them completely
    >>> open.

    >>
    >> I think it depends on the design of the switcher logic. I.e.,
    >> some turn the switching transistor on at each clock edge -- and
    >> then decide when to turn it *off* based on "current conditions".
    >> So, the minimum on time of the switching transistor determines
    >> how much energy you've put into the output stage hoping for a
    >> load...

    >
    > I consider that an unsafe design :)


    Dunno. I'm just recalling the few SMPS controllers I've used in
    the past...

    >> Swamp coolers are BFM. Every time I think I understand how to
    >> "use" one (control it), I get screwed. One thing that I *have*
    >> learned is that once the indoor temperature starts creeping up,
    >> there's nothing you can do to stop it.

    >
    > That's the weird thing. You can stop it from creeping up or at least
    > slow its rise, but you can baerly make it get down again. In the
    > evenings we can, but even then very slowly.


    Yes. Logically, you should be able to cool a house *quicker*
    with a cooler (assuming suitable RH) than with an ACbrrr.
    The ACbrrr is "indirect acting" -- it tries to suck up heat in
    the evaporator and pump it heat out of the house through the
    condenser. This should be more inefficient than "replacing the
    air in the house"! :>

    >> I suspect there must be a science behind "optimal control",
    >> there. E.g., how much to vent to the outside for a given
    >> current operating rate, outdoor wind speed/direction, etc.
    >> It would be fun to motorize the window and let a machine
    >> "learn" how to do this...

    >
    > I've tried experimenting with that. No luck. There comes a point where
    > the moisture in the house starts to rise when you close the windows too
    > much. But beyond that the cooling efficiency seems to be about the same.


    Closing too much leads to rapid increases in interior RH.
    OTOH, if the windows are *open* to much and don't present enough
    "back pressure" to keep wind from pushing HOT AIR back into the
    house...

    I think the real solution requires monitoring wind speed and
    direction, plus outdoor temperature and RH. *Then*, being able
    to control individual "window exhausts" to vent enough air
    while admitting the least amount from the outdoors. I have
    been adding instrumentation to do exactly this. What remains
    to be done is an unobtrusive mechanism for the venting...

    We're debating a large skylight in the kitchen. I look at that
    as an opportunity to vent (warm, ceiling) air from a large
    area, quickly. (but, we haven't yet decided for or against)

    >> I think I am going to explore the possibility of replacing the
    >> fan (squirrel cage) in the cooler with something that works
    >> effectively in both directions -- turn the cooler into an
    >> exhaust fan for use at night/early morning.

    >
    > Exhaust would turn it into a whole house fan.


    Exactly.

    > I wouldn't want that
    > around here because it'll suck in all the pollen and dust. My wife would
    > have a fit.


    The cooler already does that. Except it *blows* the air into
    the house instead of sucking it in through the windows. (this
    is one of the big complaints we have re: the cooler -- allergies)

    A better solution might be a ground-sourced heat pump. Or, even
    just the air intake!
     
    Don Y, Jun 19, 2011
    #18
  19. Mr.CRC

    Joerg Guest

    Don Y wrote:
    > Hi Joerg,
    >
    > On 6/19/2011 10:08 AM, Joerg wrote:
    >


    [...]

    >>>>> ("Um, maybe because I think there are other, more interesting,
    >>>>> things to spend my time on??")
    >>>>
    >>>> There's always more interesting projects or new ones but to me it's a
    >>>> matter of loyalty to see the client through to the final goal, even if
    >>>> they had a serious schedule slip.
    >>>
    >>> As an *employee*, this was no big deal. If the M.E.'s couldn't
    >>> get the mechanism working properly, you were still getting paid.
    >>> Or, if the I.E. didn't have the casing design complete. It was
    >>> your boss' job to figure out how to get suitable work out of you
    >>> given the bottleneck.
    >>>
    >>> But, on my own, I can't afford to be idled for a month, six weeks,
    >>> etc. if someone has to turn the crank again on some custom silicon.
    >>> And, what if *that* turn goes bad? Or, something else creeps in?
    >>> There's no billable hours there. And, I can't take on another
    >>> contract, in good faith, knowing that 6 weeks hence I will have
    >>> to put *that* on hold.

    >>
    >> I always have several assignments concurrently. Some urgent, some not so
    >> much. It's like with doctors, usually you only need them when sick and
    >> the workload you present is unpredictable to them unless you have some
    >> sort of chronic illness.
    >>
    >> Working for just one client is risky. What if they go belly-up?

    >
    > I'm not talking about hitching your cart to a single client.
    > But, the costs of moving between projects aren't small. And,
    > *you* bear those costs (how are you going to conscientiously
    > bill your clients for your inefficiencies at juggling two or
    > more concurrently?)
    >
    > A (typical) doctor can move between patients in 15 minute intervals.



    So can I. Seriously, it is very normal for me to be talking about a chip
    design at 8:15, then an EMC problem on an aircraft at 8:30, and some
    power electronics for a third client at 9:00. Interruptions because of
    an urgent issue are also not a problem. But you must be diligent in
    starting and stopping several time registers.

    Time recording is done on the fly and computerized. Each client has a
    separate file and the strtict rules is "file closed and put away when
    moving to another client's project". That takes, oh, about 5sec. I
    gladly eat those 5secs each time :)

    If I need to work on something that requires high focus I switch the
    phone to answering machine and ignore email arrival alerts during that
    time frame.


    > There isn't much *immediate* follow through -- "Go try this and
    > let me know what happens". Imagine a surgeon leaving a surgery
    > partially completed because some bit of kit wasn't available at
    > the time... wandering into the *next* surgery, starting on that
    > one, then wandering back to the first one when the necessary
    > items became available. :-/
    >


    My dentist does exactly this and he ain't no spring chicken, >70 now.


    >>> It's also very hard to put down a piece of software and come back
    >>> to it months later and know where you were headed. It's not like
    >>> a schematic where you can see *everything* on (dozens?) of pages.
    >>> People forget that you haven't done anything on "their project"
    >>> in "all these weeks" and wonder why you're "so late"...

    >>
    >> That's why I keep harping on documentation. Some SW guys think that a
    >> few comments in the code is sufficient documentation. It ain't. For

    >
    > You're preaching to the choir, here!
    >
    >> anything I ever designed there is a module spec, whether the client
    >> wanted it or not. I can't work any other way, or won't. This allows me
    >> to hop back into the same saddle 10 years late.

    >
    > But there is a big difference between the effort required to
    > prepare a good software specification -- let alone the formal
    > *documentation* -- and a similar one for a piece of hardware.
    > E.g., I have 100 page documents just describing the *accounting*
    > (money) subsystem in gaming devices -- without even mentioning
    > how the "game" works!
    >
    > By contrast, when documenting hardware, I get a big headstart
    > just by preserving copies of all the datasheets used in the
    > design (you typically don't have similar documents for the
    > software "components" used in a software design -- unless you
    > want to consider the language manual and processor instruction
    > set as "components"... pretty crude).
    >
    > The software industry is lacking a *good* tool to make software
    > documentation easier, more complete and more *accurate*. There's
    > no "pictorial shorthand" like schematics, timing diagrams, 'scope
    > traces, etc. Too much relies on words. Words take a long time
    > (relatively speaking) to parse. And, require a lot of effort to
    > verify.
    >


    The only tools you really need are a word processor plus MS-Paint
    (seriously, MS-Paint). Write it while coding and never let the coding
    get ahead of the document. Just like I'd easily get carried away in
    SPICE and could end up with half the circuit done but white sheet in the
    document. So I brace myself. It was hard in the first 2-3 years of my
    career but not anymore.

    Ok, I often use my CAD to create flow charts, firmware documentation and
    such. But only because it's paid for, it's there, and I am so much used
    to it.


    > And, since software is so (relatively) easy to change, it becomes
    > a cat-and-mouse game where the documentation is always struggling
    > to keep up with the latest (ahem) "enhancements".
    >


    It ain't any easier in HW. Write first, then code or design. Not the
    other way around. Sometimes that is a time-saver all by itself. While
    writing I sometimes lean back, squint, and darn, it won't work that way.


    >>>> The problem was the power supply. They needed a better one. I never
    >>>> understood why some switchers have min load requirements. I've designed
    >>>> a lot of switchers and none ever had that. You can run them completely
    >>>> open.
    >>>
    >>> I think it depends on the design of the switcher logic. I.e.,
    >>> some turn the switching transistor on at each clock edge -- and
    >>> then decide when to turn it *off* based on "current conditions".
    >>> So, the minimum on time of the switching transistor determines
    >>> how much energy you've put into the output stage hoping for a
    >>> load...

    >>
    >> I consider that an unsafe design :)

    >
    > Dunno. I'm just recalling the few SMPS controllers I've used in
    > the past...
    >


    There used to be a lot of junk out there in the 80's and 90's. From
    folks who likely didn't quite understand what they were doing.
    Seriously, when I asked one engineer what would happen if we ever dipped
    below min load he said "Well, it'll usually just squeal but if you get
    much under 10% load it might blow its guts out". I refused to use that
    thing :)


    >>> Swamp coolers are BFM. Every time I think I understand how to
    >>> "use" one (control it), I get screwed. One thing that I *have*
    >>> learned is that once the indoor temperature starts creeping up,
    >>> there's nothing you can do to stop it.

    >>
    >> That's the weird thing. You can stop it from creeping up or at least
    >> slow its rise, but you can baerly make it get down again. In the
    >> evenings we can, but even then very slowly.

    >
    > Yes. Logically, you should be able to cool a house *quicker*
    > with a cooler (assuming suitable RH) than with an ACbrrr.
    > The ACbrrr is "indirect acting" -- it tries to suck up heat in
    > the evaporator and pump it heat out of the house through the
    > condenser. This should be more inefficient than "replacing the
    > air in the house"! :>
    >


    That is what I really don't understand (yet). For example, today the
    cooler has run for 5h or so at half power, outlet temp 68F. Yet the
    house sits solidly at 75F even though the cooler must have exchanged the
    air about 15 times over. Now 75F is much more comfy than the 82F it
    would be without but still it's a puzzler.


    >>> I suspect there must be a science behind "optimal control",
    >>> there. E.g., how much to vent to the outside for a given
    >>> current operating rate, outdoor wind speed/direction, etc.
    >>> It would be fun to motorize the window and let a machine
    >>> "learn" how to do this...

    >>
    >> I've tried experimenting with that. No luck. There comes a point where
    >> the moisture in the house starts to rise when you close the windows too
    >> much. But beyond that the cooling efficiency seems to be about the same.

    >
    > Closing too much leads to rapid increases in interior RH.
    > OTOH, if the windows are *open* to much and don't present enough
    > "back pressure" to keep wind from pushing HOT AIR back into the
    > house...
    >
    > I think the real solution requires monitoring wind speed and
    > direction, plus outdoor temperature and RH. *Then*, being able
    > to control individual "window exhausts" to vent enough air
    > while admitting the least amount from the outdoors. I have
    > been adding instrumentation to do exactly this. What remains
    > to be done is an unobtrusive mechanism for the venting...
    >
    > We're debating a large skylight in the kitchen. I look at that
    > as an opportunity to vent (warm, ceiling) air from a large
    > area, quickly. (but, we haven't yet decided for or against)
    >


    I can imagine that a large opening in the ceiling could be the ticket.
    But we don't have a skylight. If we were in your shoes the debate would
    have taken 10sec, max :)


    >>> I think I am going to explore the possibility of replacing the
    >>> fan (squirrel cage) in the cooler with something that works
    >>> effectively in both directions -- turn the cooler into an
    >>> exhaust fan for use at night/early morning.

    >>
    >> Exhaust would turn it into a whole house fan.

    >
    > Exactly.
    >
    >> I wouldn't want that
    >> around here because it'll suck in all the pollen and dust. My wife would
    >> have a fit.

    >
    > The cooler already does that. Except it *blows* the air into
    > the house instead of sucking it in through the windows. (this
    > is one of the big complaints we have re: the cooler -- allergies)
    >


    Big difference: The aspen pads catch lots of dirt, the water flushes
    that into the basin and there it sinks to the bottom. After dust or
    pollen storms it's good to clean that out. Easy to do, just open a
    panel, shut off valve, pull a piece of pipe, gurrrrrgle ... shhhhlurrrp
    ..... wipe bottom with Kleenex, put panel back in, open valve again ...
    done. That's why I made a discharge pipe for it. The whole process takes
    maybe five minutes. I actually find the air quality to be better than
    without the cooler running but that may just be my personal preference.


    > A better solution might be a ground-sourced heat pump. Or, even
    > just the air intake!



    Air intake? That how we often run it, blow in fresh air but without the
    water cooling.

    --
    Regards, Joerg

    http://www.analogconsultants.com/

    "gmail" domain blocked because of excessive spam.
    Use another domain or send PM.
     
    Joerg, Jun 19, 2011
    #19
  20. On 18/06/2011 12:01, Bruce Varley wrote:
    > "Mr.CRC"<> wrote in message
    > news:...
    >> > Paul E. Bennett wrote:
    >>> >> Mr.CRC wrote:
    >>>> >>> There are no written specs.
    >>> >>
    >>> >> That is the first big mistake.
    >> >
    >> > I'm not sure that in the research environment, there is any other
    >> > choice. I mean, I can write some specs for them, such as electrical
    >> > specs. But for behavior, there was no way 5 years ago for us to foresee
    >> > what experiments would need to be done today. They would simply
    >> > complain to the manager that I wasn't serving their needs if I asked
    >> > them to specify anything so precisely. They want me to figure out the
    >> > precise details of what they want, for them.

    > <snip>
    >> > Mr.CRC

    > OK, this is not a trivial situation, it's about*culture*. For starters,
    > whatever anyone says, everyone's job contains elements of what you describe.
    > During every project small changes will be progressed on the fly, sensible
    > implementers will then follow up with an email or something, "confirming our
    > discussion of ..., I have ...).
    >
    > From what you describe, however, this is a situation which lacks many
    > essential controls, and where a lot is happening that shouldn't, and which
    > you probably aren't aware of.
    >
    > If you really want to attempt to change culture, then I suggest you do a lot
    > of reading, and talk to people who are experienced in management, then think
    > very hard before you leap in. It's a dangerous game for the inexperienced,
    > you could end up badly burnt out, disillusioned and damaged - for life.
    >
    > Your alternatives are to play the game and at the same time make small
    > changes that you judge you can without upsetting too many stakeholders, or
    > to opt out.


    Very sensible response.

    I have to be a little careful what I say here. My boss might read this ;).

    I've worked in high-volume environments, where everything was planned
    out, and all the ISO procedures were followed to the letter. Any changes
    to specs were followed by mountains of paperwork... and I was happy. I
    knew where I was, and what the score was.

    I've also worked in low-volume, high-value, experimental environments,
    where V1 turns into V6 at high cost, all procedures fall by the wayside,
    and mistakes get made... and it's all wanted yesterday, and tempers get
    frayed. (This describes my current job.)

    But, as Bruce says, it's a culture thing. Not too long ago, I quit after
    a *spactecular* barney with my boss, who I'd often previously defended
    (and still do) as being entitled to being a bit stressed (and hence
    loopy) from time to time. I withdrew my resignation the following day,
    on the basis that my injured pride was not a good reason to a) lose my
    living and b) kill the current (high-investment) project, for which I'm key.

    Since then, we've got on fine ;).

    It might help that I'm mid-fifties, and fairly thick-skinned nowadays
    (didn't use to be - ho no...).

    I'm hanging in there on the basis that the project is worth it, the
    folks who report to me are worth it, my boss is fallible but human, and
    I might be able to make a difference to how it all turns out longterm.

    Also, I enjoy it ;).

    Steve
    (currently working all hours to complete hardware and firmware on a
    high-value system which *must* ship next week... we *might* make it...)

    --
    http://www.fivetrees.com
     
    Steve at fivetrees, Jun 21, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Uncle Vinnie

    1.2 Tualitan- how many volts is too many?

    Uncle Vinnie, Jul 16, 2005, in forum: Overclocking
    Replies:
    21
    Views:
    774
    Fishface
    Jul 23, 2005
  2. AnotherAnonymous

    Many many errors...

    AnotherAnonymous, Mar 26, 2007, in forum: Gigabyte
    Replies:
    3
    Views:
    523
  3. Replies:
    0
    Views:
    309
  4. Replies:
    0
    Views:
    226
  5. Peter

    Many, many COM ports "in use"...

    Peter, Mar 16, 2005, in forum: Tablet PC
    Replies:
    5
    Views:
    235
    Chris H.
    Mar 21, 2005
Loading...

Share This Page