Conference 7.286::digital

    Here in Central Engineering we sometimes have college students in for
    a few months, so we've got some experience in this area.  I think the
    most useful thing a short-timer can do is develop tests for the
    regression test system.  That isn't very glamorous, but it's very
    important.  Having the developers also produce the tests doesn't work,
    because they write tests only for the parts they've thought about, and
    of course those tests pass.  What you need is an independent point of
    view, someone who can read the documentation afresh and write tests for
    the way the customers will use the product.
    
    Anyhow, it's lots of fun to write a test that breaks something, then
    watch the developers scramble around trying to fix it.  It's also good
    to know that you've saved the company money, and saved who knows how
    many customers hassle.
        John Sauter

    Depends on what you mean by "development."  I've worked with co-ops and
    found that when the assignment is less than 3 months they either do
    coding work that would bore your average SWS person or would consist of
    developing regression tests (as mentioned earlier).
    
    However, bring SWS people up to Central Engineering to do development
    would be a waste of time, in my opinion.  We already have generally
    good coders; what we don't have a lot of is customer expertise.  In
    particular, where the most bang for the buck would come in would be
    during the design phase and, maybe, visiting field test customer sites
    to give them that "warm and fuzzy" feeling.  And to get ideas for the
    next version of the product/project.

    Isn't the field fully involved in the phase review process?  I mean
    this sincerely.
    
    For the projects when there's an open call for phase 0 input, mailing
    lists, review meetings, and/or base levels and field tests, my
    experience has been nothing short of excellent.  It really doesn't
    require a "rotation" into development.

    re: .3
    
>    Isn't the field fully involved in the phase review process?
    
    Around here, I wonder if most people could _define_ the term "phase
    review process".  Needless to say, most people could not possibly
    be involved if they don't know what and when it is.
    
    _Some_ field people _may_ be involved.  If so, that's great!  I
    guess the rest of us don't "need to know" about such things... 
    :^(   (It would be interesting to see what the ratio of Sales Support
    vs. Delivery folks is in Phase 0 participation)
    
    -- Russ

    $ SET TONGUE/IN_CHEEK=FIRMLY
    $ OPEN MOUTH/INSERT=FOOT
    
    Of course, everyone knows that SWS could not possibly rotate through
    Engineering positions, as Engineering is merely a myth.  We know
    this, of course, from a) lack of any non-electronic contact and
    b) the way in which any attempt at physical contact is thwarted.
    
    We, in SWS, know that _all_ Digital employees wear suits; therefore
    the folklore regarding a Magic Kingdom in the North where people
    wear "casual" attire may be suitably discarded as urban myth.
    
    We know that it is forbidden to see Engineers in person.  It is
    "too costly" to see any of these supposed people at work.  Places
    where Engineers supposedly gather in public (such as DECUS and
    IDECUS) are not open to SWS people.  No pictures of them are
    _ever_ smuggled to the Field.  Their voices are never _actually_
    heard.
    
    The sole arguments for the existance of such mythical beings are
    1) the existance of electronic messages bearing names of supposed
    Engineers and 2) the appearance of products supposedly produced by
    said mythical beings.  We know that electronic messages could be
    produced by clever Marketing people posing as these supposed
    Engineers.  We also know that the products could be produced by
    some form of intelligent life, but this life-form undoubtedly wears
    a suit and tie like everyone else!
    
    And as for the Magic Kingdom of the North...  well, this can be
    lumped in with Santa's house at the North Pole.  Suffice it to say
    that _no one_ has _ever_ seen such a place where facilities abound
    and these mythical Engineers dwell.  All such reports are electronic
    in nature, and therefore, can be dismissed as Marketing propaganda.
    
    In fact, the existance of the state of Massachusetts itself is coming
    under question.  No one can travel to there because "it's too
    expensive".  Mike Dukakis is clearly on the same level as Santa
    Claus or the Easter Bunny (ever notice how fictional characters
    like this are very short?).
    
    $ SET TONGUE/OUT_OF_CHEEK
    
    Seriously, though, I catch myself thinking like this sometimes.
    To see actual _human beings_ doing Engineering would be _wonderful_!
    (Err, um, Engineers _ARE_ human beings, aren't they?  8^)
    
    -- Russ (who still thinks that Mike Dukakis is mythical...)

    >In fact, the existance of the state of Massachusetts itself is coming
    >under question.  No one can travel to there because "it's too
    
    Then you MUST believe in VMS and many of the LP's.  They come from New
    Hampshire.  You had me worried, there for a while.  I was thinking
    that I might not exist.  (I have been amazed at how many people do not
    realize how far north of Maine we are!)
    
    	- mark
    
    

    re: .6
    
>    Then you MUST believe in VMS and many of the LP's.
    
    Oh, of course I believe in the PRODUCTS.  They clearly exist (just
    go to a customer site and see one).  It's these "Engineers" that
    are in question...  8^)
    
>    You had me worried, there for a while.  I was thinking
>    that I might not exist.
    
    I confused you, sorry.  The fact is that you _DON'T_ exist, Mark,
    regardless of state, if you're an Engineer.  8^}
    
    New Hampshire is clearly another mythical place.  Note the presence
    of "shire" in the name -- clearly an allusion to Hobbits et al.
    
    The Engineering dwarves (living in tunnels in the Mill, shunning
    daylight, living on Twinkies and Pepsi;  note also how the smallness
    of stature ties in with the Dukakis myth) were driven from the southern
    end of the Magic Kingdom when evil Balrog Dukakis attempted to tax them
    into slavery.  They escaped to the New (hamp) Shire and built new
    facilities in which to dwell.  Note as well how this myth also ties
    into the common picture of Engineering-types wearing mountain climbing
    boots.
    
    Sorry, Mark.  You're a Marketing invention...  8^}
    
    -- Russ (who'll be back from fantasyland any time now...)

Mark wasn't invented here, and even marketing couldn't have thought him up.

		{8-)}

				Bill

>    The Engineering dwarves (living in tunnels in the Mill, shunning
>    daylight, living on Twinkies and Pepsi;
    
    That's "Fig Newtons and Orange Crush".  Some of us are very trendy (and
    the Mill machines didn't provide Twinkies).
    
John

    As a final rathole message, the previous was in great jest and fun.
    Laugh at it as I did and enjoy.
    
    Marketing...  Now that hurt. :-)
    
    Now to add value to subject at hand:
    
    I have been at customer sites.  I work in engineering.  I tend to agree
    with the idea that engineering should see the 'real' world.  DECUS is a
    good start.
    
    The real problem is communication between the field and engineering.
    
    The field feels that engineering snubs them and does not help them with
    customer problems (white tower etc...).  They are hard to get a hold
    of, don't seemto care.
    
    
    The engineering groups tend to look at the field as a bothersome pain. 
    Always wanting an answer today, this minute.  Always bothering at the
    wrong time.  Unknowledgable about the product (why don't they get
    training).
    
    I feel a lot of the problems occurrs at the management levels directly
    above the workers (field/engineering).
    
    Field would like more training, but does not have the money.
    
    Engineering needs to get a product out the door so does not have time
    to work on last months problems.
    
    	- mark

    Before we get into the rathole of discussing whether we should allow
    the rathole which we were in, let me attempt to get back to the
    subject... (And don't *ANYBODY* get me started on whether or not
    these fictional Engineers live in ratholes!!!  ;^} )
    
    My point is this:  I know a little something about being a Software
    Engineer, as I was one for several years for another company.  I
    obviously don't know all about many of the Digital-specific problems
    that our Software Engineers face, but my knowledge of the task at
    hand, combined with the "short-circuit" (was it Martin who used that
    term?) of Notes, allows me to get a general understanding of what
    our Engineers must go through.  As such, I can put on my Engineer's
    hat when dealing with customer problems and make (hopefully) a
    reasonable guess at what information might be necessary when reporting
    a problem to Colorado/Atlanta.  I find that many SWS folk can't
    do this very well, as they have never had an Engineering experience.
    
    Personally, I would hope that exposure to an Engineering situation
    might also serve to impress upon Specialists then need to sharpen
    technical problem solving skills.  I am _appalled_ by the number
    of Specs I have seen who will call Colorado/Atlanta every time an
    error occurs.  I know what it is like to debug problems remotely
    with only sketchy information -- it's no fun!  Even though the Spec
    may not have access to source code, the Spec is _still_ in the best
    position to attempt a preliminary diagnosis of the problem.  The
    need to define a problem as precisely as possible and isolate exact
    cirumstances under which it can be reproduced (and, where possible,
    hypothesize about the nature of the malfunction) is, in my mind,
    a critical issue for referring a problem.  A Spec who has had to
    function as an Engineer is more likely to undertake this task, knowing
    its value.  A Spec who has never debugged anything except small
    modules (if that) seems far less likely to do the advance work.
    
    It boils down to this:  we need to work as a team to solve problems.
    However, it is nearly impossible for a team to function well when neither
    group has the knowledge or appreciation of what the other group
    has to go through to perform the tasks within its mandate.  Exposure
    to other team members and their work situation is a clear and distinct
    path to improving overall teamwork.
    
    -- Russ

    Back to the subject that began all of this.  As for background
    I've spent half of my DEC career with an R job code.  Now I don't
    exist.
    
    Places that SWS would be useful in Engineering:
    
    Before Phase 1 closes working on prototype development. 
    
    From experience SWS people who have had to work on customer projects
    (especially fixed price ones) can generate the appearance of working
    code in amazingly short periods of time.  
    
    During field test developing demos.
    
    The need to show off the product often is delegated to one of those
    summer hires or a recent college grad as a learning excercise. 
    Having something that shows off our products as applications that
    would make little lightbulbs go off in customer's heads and little
    dollar signs appear on orders would add more marketing focus to
    our engineering side projects.
    
    During the specification and design phase of the projects.  
    
    Engineers often complain that SWS doesn't know how product X works.
    The engineers know product X like the back of their hand.  Its products
    A, B, C, G,F, H,Y and Z that the specialist has expertise with.  It
    would add a lot of perspective to our selection of existing products
    upon which to build.
    
    During Phase 0. 
    
    The increasing need for product management to become financially
    oriented has cost us a lot in customer expertise and field knowledge
    when putting together requirements.  If a group of specialists wrote
    the first draft of the requirements the product management job would
    have a good foundation upon which to build.
    
     
    Testing.
    
    The imaginative mind of someone not too closely connected with the
    product often results in lots of things being fixed before they
    reach the customer.  Quality development requires a lot of tools,
    organization and time.  Having only junior people attending to it
    is not the best solution.
    
    Basically we could use some help at any point between conception
    and delivery with the exception of actually writing the code.  And
    even then the hands might be welcome.
    
    
    Now if there are a few field people who'd like to take the John
    Sauter path of vacationing in la la land, I could use some people
    with network design skills, ACMS skills, hands on network management,
    a couple of network performance wizards ....
    
    kevin
    
    

	I think one outstanding example of a product that could have used some
input from the field is VAX PM.  I think that product would have looked a WHOLE
lot different if some people from the field who had to PLAN customer projects
had been active participants in the design.

    
    re ,16
    
    HEAR! HEAR! HEAR!
    
    If VAX PM has PSS input and met PSS needs, we would not have to
    go outside the corporation and spent 100's of thousands of $s on
    third party products!
    
    Rv

    I really believe that if (big IF) you wish to be involved and if
    (big IF) the product management folks for the particular product
    are also interested, then a normal (read: mortal field person) can
    participate in Phase Review (at least at Phase 0/1).
    
    This certainly seems to be the case with ALL-IN-1 2.3 and pfr's.
    In fact, not only was I allowed/encouraged to participate, the product
    management (Thanks Gerry!) participated in our (Ed. Services) update
    training/symposium to make sure we understood the reasons the product
    changed and looked the way it did.  
    
    And I don't write code.
    I don't write scripts.
    I am NOT a programmer. 
    
    But I DO spend lots of time with customers in training every week,
    and hear what they like and do not like.  And feel free to pass
    that information through to the proper groups. 
    
    Of course I wouldn't have been involved in ANY of this without NOTES.
    
    
    /s/getting_down_from_soapbox_now

    These last two topics have been interesting - should engineering see
    how the other half lives - and should the underclass get to visit the
    ivory tower!  
    
    So, how many of y'all want to come out here and fight for a VT220? 
    Maybe order a VAXstation and hope it gets here before its TOO obsolete
    (it DIDN'T).  See the wild world and visit customers... Great.  Come on
    down!  Maybe you can do something about the overwhelming tendency to shove
    3rd party products down the throat of every problem, instead of selling
    custom software projects (oh, damn, wrong rathole).
    
    But, as far as having the great unwashed visit Engineering... how you
    gonna get them to go back to the ghetto after they see the Emerald
    city?  Personally, I'd love to be in Engineering - Have all the newest
    hardware and software toys, not have to fight for every penny-ante
    piece of anything, and and NEVER see another customer!  Anybody want a
    field Principal Software Specialist that wants to do design, coding,
    testing instead of meeting, meeting, meeting?

     Engineering isn't as much fun as you imagine.
    
    I should know, working for CSSE, I sit on the fence between Engineering
    and the Field and see both sides.
    
    Andy (who worked 3+ years in the UK Customer Support Centre)

    I suppose that Engineering varies from place to place within Digital.
    Perhaps I haven't seen the parts that Andy Leslie refers to in 753.20,
    because I've always found it to be fun.
    
    .19---``Have all the newest
    hardware and software toys, not have to fight for every penny-ante
    piece of anything, and and NEVER see another customer!''
    
    That's exactly the Engineering that I experience, except I occasionally 
    get to see a customer.  Indeed, I wish I could see customers more often.
    A few months ago I was assisting in a presentation to a customer, and
    one of his technical people made a suggestion for improving the
    product.  It was a very minor thing, from a product development point
    of view, but it would save nearly every customer a small hassle.  I was
    non-commital to the customer, of course, but I'm happy to say that I
    managed to get his feature into the code before we shipped.
    
    I suspect that customer input during the deveopment process could
    significantly improve our products.  Even if the only thing field
    people can bring to Engineering is the customer perspective, that would
    be enough to justify a rotation program, in my opinion.
        John Sauter

>               <<< Note 753.21 by SAUTER::SAUTER "John Sauter" >>>
>                         -< it's fun from where I sit >-
 
    Absolutely, working in Engineering can be a real ball. However, there
    are Engineering groups in which being under-resourced and under-funded
    is a way of life.
       
>    I suspect that customer input during the deveopment process could
>    significantly improve our products.  Even if the only thing field
>   people can bring to Engineering is the customer perspective, that would
>    be enough to justify a rotation program, in my opinion.
>        John Sauter

    I look upon this as at least part of CSSE's function. That's certainly
    the way *I* play it.
    
    Andy

Would those of you in engineering who are having a real ball be willing
to share the names of your groups with the poor slobs in the field who
don't know the diiference between MRO and MLO?

John

    Take a look in the VTX Jobs Book.... there were plenty of ENgineering
    jobs the world over, last time I looked.

    Yes Andy there are lots of jobs but the question was which jobs are
    fun. Seems to me that most JOBS entries don't comment on how much
    fun the job is. :-)

    BTW, my group has tons of hardware and is doing all sorts of
    interesting things. Needless to say what we don't have is open
    reqs. :-)

    				Alfred

    All jobs are fun - life is what you make it! :-)
    
    Seriously, look for a job working on something that you are interested
    in, that way you know you'll have fun.
    
    Andy

    re: .23---I'm in the Core Applications group, cost center 3FH,
    under Jeff Rudy.  I don't know if we have any open reqs, but we just
    added a person to the group yesterday.
    
    re: .26---I agree.  I am interested in lots of things, perhaps that's
    why I have so much fun.
        John Sauter