Conference 7.286::digital

    I saw this too and had more-or-less decided to  ignore it as it doesn't
    say what priority the SPR's were or what products they were upon.
    9 months would be terrible for a priority 1 (system crasher) bug, but
    okay for a priority 5 (suggestion).
    
    Thus the stats are meaningless.
    
    If you wish to take this up, do a followup in NEWS asking they contact
    the CSC, who have people paid to deal with customer queries such as
    this.
    
    - Andu

    
         The other side of this is that unless the site where these
    SPR's are coming from is running field test software, I would
    really start wondering why there were SO MANY SPR's in such
    a short time.
    
    I've seen cases where a site has someone that likes to get their
    name "in lights" so to speak. This was especially prevalent for
    SPR's that got published. It was quite evident that some people
    get a kick out of having their name show up on multiple SPR's
    EVERY time a dispatch was published.
    
    						Warren
    

    I'm not surprised about "suffering" SPR's. In order to get a
    "better grip" on real problem SPR's, Europe turns customer's SPR's
    into calls at first level of service delivery. (TSC's ore whatever
    they are called). The goal is to fix them right there. In case the
    call (ex-SPR) can't be solved at that level, it'll probably wind
    up at Area level as either escalated or non-escalated call.
    For true engineering problems, usually the escalated calls become
    CLD's the non-escalted ones "Area SPR's". The stats show that despite
    the decreasing number of SPR's (due to the new process) the response
    time didn't improve.
    My impression is that there aren't just enough resources to fix
    problems, in particular while Engineering's goal is to develop new
    stuff and not to sustain current/past versions.
    Fred
    

    
    I must agree with .1 - 
    This data is difficult to interpret not knowing the priority or the 
    product they are filed against. System crashers inevitably turn into 
    CLDs, so I doubt many of these  SPRs are system crashers.
    
    Efforts are being made at the corporate level to decrease the time it
    takes for a customer to get a response for high priority SPRs,
    all SPR's for that matter.
    
    Let's also be realistic; many "high" priority SPRs have no business
    being "high". RTFM SPR's for example.
    
    The approach .3 mentioned is a good way to help avoid the SPR latency.
    In the US, SPRs are screened for immediate answer at the CSC's, if
    necessary they are then elevated.

    I think it is very important to understand that "Engineering" is not
    a single organization, especially when it comes to answering SPRs.
    Each group has its own policies.  In my own organization, TL&E (who
    bring you such products as FORTRAN, Ada, DEBUG, and SCA), we
    generally put maintenance ahead of new development.  On both my
    current (FORTRAN) and past (Ada) projects, SPR answering was the
    highest priority - we drop what we're doing and answer those SPRs
    as quickly as possible.  Our view is that this increases customer
    satisfaction and also allows us to improve the quality of the product.
    
    Some other groups (I could name names, but won't), have the
    opposite policy.  It is these groups that tend to pile up the
    year-old SPRs.  Unfortunately, one of the projects I am familiar
    with tends to get a LOT of SPRs, so the problem just gets worse.
    
    A small set of problems is caused by the multiple hands that an SPR
    passes through before it gets to us.  I've seen SPRs show up that
    had been sitting on someone's desk (in SPR Administration, usually)
    for nine months.  And then WE get charged for the delay!  Luckily
    these problems are few and far between.
    
    If you have a customer who is complaining about slow SPR response,
    have them give you the SPR numbers (preferably the ones assigned
    by SPR administration and sent back to the customer with the
    acknowledgement, but if they just have the paper SPR number, that
    will do.)  These can be traced by SPR Administration.  Unfortunately,
    there is at the present time no system for following up on old
    SPRs automatically - it has to wait for a complaint.
    
    I know that my group considers customer satisfaction the top
    priority, and we not only respond to SPRs quickly but we usually
    include a correction kit with our response.  Unfortunately, our
    good work is overshadowed by other groups who use SPRs as
    wall insulation.
    
    It would be nice if these problems didn't occur, but a few
    inquiries can perhaps help things along in times of trouble.
    
    				Steve

    re .5
    Thanks, Steve!
    Maybe after all the reason why I don't see many CLD's against your
    products is not that they don't sell a lot !
    If I'd ever compare number of licenses sold versus numbers of
    CLD's and/or SPR's, there could be surprises.
    Fred

RE: < Note 823.5 by QUARK::LIONEL "in the silence just before the dawn" >

Your statement matches what I noticed as a customer.  Whenever I sent in
an SPR for one of your group's products, say, FORTRAN I got a response
AND A FIX within a reasonable time.  For other products (I won't name
names) I learned that filling out SPRs was a waste of time.  

John

    Some engineering groups have a very well defined goals for SPR
    turn around time and their product support people are measured on it.
    But, if the customer really cares for having support, we have support
    contracts with much better comittment then an SPR letter service.

    So, yet another aspect of the call statistics in 0., did the customer
    have a support contract ? What was and where did he get response time
    expectations from ?
    
    
    				wlodek
    

    There's really a problem now as the field is trying to phase out SPRs
    (TIME cases) in favor of escalated calls.  Unless Engineering is held
    accountable for turnaround of escalated calls, they'll drop to the
    bottom of the pile.  SPRs, as good or bad as they may be, are at least
    measured.  
    
    When an engineer says, "Submit an SPR," from my perspective they're
    saying "please formalize your request/complaint so that I can formally
    work on your problem...and be productive in ways that my management
    considers productive."
    
    Marge

    From our perspective, paper SPRs are identical to problems reported
    by the support centers (at least those that result in formal problem
    reports - unfortunately some support people insist on using notesfiles
    as a problem reporting method and don't understand why their
    problems seem to get ignored.)
    
    Our management does get reports from SPR administration of SPRs that
    are open more than a reasonable time (30, 60, 90 days, etc.)  The
    problem is that some products get such a volume of SPRs that it is
    difficult to get any work done.  Sometimes it's a flaky product,
    other times its a complex one that customers have a hard time
    understanding.  But the result is that if there is a backlog measured
    in four digits, you're not going to see a speedy resolution.
    
    CLDs are a new thing to us, and we don't know what to do with them.
    As Marge says, we aren't measured on CLDs, just screamed at for them.
    It doesn't make us feel terribly helpful to have one of these things
    land on our desks, with threats of dire recriminations if a response
    is not forthcoming yesterday, when we had never heard of the problem
    until that moment.  My take of the situation is that a migration to
    CLDs is only going to make the problem a hundred times worse.
    
    				Steve

    CLD's have been around for at least 3-4 years.  A SPR'd system crasher
    and CLD are really the same thing.

    A concerted effort is being applied to SPR's by engineering and the
    various groups along the way (for VMS at least).  Again, speaking for
    VMS, it has one of the highest SPR's rates and also one of the hardest
    jobs to figure a problem out.

    I get a real kick out of the person who sends a dump in and says, 'My
    system crashed.  What happened?'.  A person can spend many hours trying
    to find what happened.  Most of the time, a person spends 10 minutes
    and if there is not anything obvious, says I have no idea and moves on
    to his next project.

    A good 30-40% (probably more) of the SPR's that make it to VMS need
    further customer contact.  The customer does not supply enough
    information, incorrect information, invalid dump's, does not pass the
    console listing etc...

    This is where the CSC's entering the SPR can help.  They can make sure
    that a consistent and usable SPR is entered.

    One interesting suggestion occurred at DECUS, though.

    Create a procedure/program to automate the submitting of SPR's.
    (BACKUP/IGNORE=NOBACKUP)  Ask all the correct questions.  Grab the
    SYSGEN parameters, process dump's.  It would then create a standard
    file, that would describe everything that was on the tape.

    This would then be written to some media and shipped out.  Once it
    reached SPR admin, the would run a program that would parse the files
    and automatically assign an SPR number and mail a response to the
    customer.  This information could then be electronically passed on to
    the correct people.  This is slanted toward VMS, as you can tell.

    	- mark

    Folks, we are getting right down the cause of the SPR/CLD dilemma
    thanks to your reecnt contributions.
    SPR's make engineering tick..
    whereas the field and CSSE ticks on CLD's.
    There is a definite mismatch of mutual expectations.
    The idea of .-1 about automation of SPR's is good one, (for later)
    but only would solve SPR admin problems.
    I'd really like to see Engineering follow the field/CSSE trend and
    implement commitments, measure on CLD's. It will not only help us
    (field) but also Engineering.
    As mentioned in one of the replies there a lot of "junk" SPR's coming
    directly from the customers. Who would dare blaming them ? Don't forget
    they pay our salaries. Furthermore technical customers are becoming
    "rare species".
    What's the advantage then of a CLD to engineering ?
    A good CLD is a call to which a LOT of value has been already added
    before it hits engineering. It has been carefully evaluated both
    technically and with respect to the impact of the problem on the
    customer's or Digital subsidiary's business to deserve the high
    priority attention by Engineering when they receive it thru CSSE.
    Marge (Hi Marge,) might say
    "C'mon Fred, you did and do submit junk CLD's". Sure, because the
    world ain't perfect and DIGITAL even less. However, fellow CLD
    managers and myself do try hard to make it happen. If you think
    a particular CLD is junk, at least you have someone who feels
    responsible for it and with whom you can negotiate, discuss.
    Whereas for an SPR, who would you call ? There ain't much management
    (problem-management that is) focus on any SPR's. Sure some folks
    produce numbers and get all excited about them. But I don't think
    that anyone could convince me that any number could be translated
    directly into "customer satisfaction or dissatisfaction".
    It's funny (or sad) to note that within DEC we strongly believe
    in "our way of working", which is mostly informal, personal
    network, notes etc... but in terms of "official business" we
    ignore it.
    Why do we need to handle every little question, problem thru
    official channels ? A good support engineer should be capable
    of using personal judgement, knowledge, network to solve a
    problem in the best interest of the customer and DEC. The
    few ones left, she/he cant do deserve than "exception management"
    focus and turning on the heavy problem escalation machinery.
    A little more trust and faith and recognition towards our first
    line support folks would sure make things better.
    Unfortunately the harder we try to channel, formalize, automize
    first line service delivery, the more we create exceptions, which
    don't fit the "model" and for which we spent a lot of overhead.
    The costly overhead rarely shows up in the stats which only
    measure the "model's" effectiveness but not that of the real world.
    Nough for today, back to CLD's..
    Fred

    Quick comment to keep me in good graces with Engineering:  my
    Engineering counterparts have given us fantastic response to CLDs... 
    ...and the ever-so-infrequent (hi, Fred :^) "junk" CLDs shouldn't get 
    to Engineering, since we're a go-between in CSSE....
    
    Marge

    There is a formal agreement between Engineering VP and Service VP,
    committing Engineering to respond to CLDs. So, CLDS are recognized
    although it practice CLD measurement are probably not in place yet.

    					wlodek

Re: .15

Could someone explain what a CLD is?  (I'm in blissful ignorance so far.)  From
a developer's standpoint, how is dealing with a CLD different from dealing
with an SPR?

				-- Bob

    A CLD (which stands for Central Logging Desk, not a very descriptive
    acronym) is the highest level of escalation within Field Service. 
    Field Service is responsible for service delivery of those service
    contracts which are an extension of product warranty, as distinguished
    from consulting services or software projects.
    
    CLDs get "logged" at the area level, from desks in Colorado Springs,
    Acton, Valbonne, Basingstoke, Atlanta, Westboro (MA), Kanata (Canada),
    and Munich.  There's a listing for a CLD desk in LAC, Deerfield Beach,
    one of the GIA desks, but I've never seen a CLD logged from there so
    don't know about it.  From the area desk they go to the Central Logging
    Desk in Stow where they are parceled out to the correct CSSE support
    group.
    
    There is joint ownership of a CLD: the field and CSSE.  Each CLD has
    assigned to it a problem manager from CSSE and the field and a
    technical person from each organization.  Together they determine,
    insofar as possible, what the real problem is and, when needed, CSSE
    pulls in Engineering to help effect a resolution.  [In some instances,
    there is no resolution and product management writes up a position
    statement to be presented to the customer.]
    
    From an Engineering perspective, I believe that the major difference
    between a priority 1 SPR and a CLD would be that CSSE and the field
    have primary ownership of a CLD, whereas Engineering has primary
    ownership of an SPR.  From a content and criticality viewpoint, they
    are similar.
    
    CLDs are managed per a formal "action plan" which is devised for each
    CLD which gets logged.  The action plan states what resources are being
    applied to the problem, what the communication path is, frequency of
    communication, actions to be taken at both ends (field and
    "corporate"), etc. Problem management (communication) is probably as
    important a component to successful resolution of a CLD as is the
    technical resolution.  Many, many times a CLD is opened when a customer
    is really "hot"....V.P. calls and K.O. calls, lawyers salivating, etc.
    
    As Fred mentioned in a previous reply, a great deal of work is done on
    the CLD to qualify it and make sure the problem is reproduceable before
    Engineering is pulled in.  If Engineering needs additional information,
    they can go back to CSSE who will make sure that the information is gotten.
    
    CSSE is measured on days to close a CLD, just as Engineering is
    measured on days to close an SPR.  Closure does not always require a
    problem fix, but often a workaround acceptable to the customer will
    suffice.  Formal closure occurs at "corporate" level when both the
    field and CSSE agree that closure can occur; usually this includes some
    period of time to monitor the fix once it's installed. The area may
    keep the CLD open at the area desk to continue to track the customer
    thereafter.
    
    Marge
      

    The way we do it in IBM Interconnect Engineering is as follows.
    We'll answer a few questions on a CLD but if it needs more work than
    that the NCSS (CSSE type) folks will generate an SPR and reference
    the CLD. Engineering get their SPR, NCSS then bug engineering about the
    SPR and not the CLD.
    
    Dave

    Dave, out of curiosity, are you on TIME?  Difficulty generating
    electronic SPRs here that don't go back through the admin loop...
    
    tnx,
    Marge

    Let me just wish each of you a happy holiday... this is the first
    Friday I've worked prior to a three-day weekend during which I didn't
    receive a new CLD to work... 
    
    I'll take rain over a CLD!
    grins,
    Marge

By coincedence I came across this notes_file entry and here my reply.

My opinion on SPR's is following:

An SPR is either a Customer problem (1) or a Customer suggestion (2).

1. For Customer problems we have a problem escalation process.
    Customer calls in his problem by telephone (normally NOT by letter)
    and the local organisation will do a solution attempt.
    In the case the local support organisation is not able to solve the
    customer's problem, it is escalated through the normal channels.
    In this way it is made sure that all available resources are used
    before the problem ends up in CSSE/Engineering and the chance for garbage
    SW problems (SPR's) is eliminated.
    Depending on the urgency, CSSE coordinate the Customer problem solution 
    in SW Engineering, either as a CLD or a Non_Time_Urgent Problem.

    I am convinced that we better get rid of the Paper_Call_Method (SPR's) 
    a.s.a.p. In this way, it will be much simpler for our customers to use 
    ONE problem reporting channel, the direct contact with the local 
    organisation. And most important, we are then also able to set the right
    expectations with the Customers upfront.

2. For Customer suggestions (for which SPR's were initially intended !),
    we better develop a Suggestion Input channel (S.I.'s ?) which will than
    be forwarded straight into SW engineering from the local office.
    (No problems, only it_would_be_nice type of inputs.)
    These suggestion inputs can than be used by engineering and marketing
    for the development of new versions and new products.
    Here also, set the right Customer expectations upfront !
     
                                                 Henk van Vuuren      

    

    Re: .20
    
    SPRs were *intended* to be used for customer problems as early as 1970
    and perhaps earlier. They were also used for customer suggestions.
    Sometimes the Digital person answering the SPR would simply declare the
    "problem" to be a "suggestion" if it seemed the customer had a
    reasonable work-around. 

Re: .21

>    Sometimes the Digital person answering the SPR would simply declare the
>    "problem" to be a "suggestion" if it seemed the customer had a
>    reasonable work-around. 

That's a tempting way of answering an SPR or QAR:

"My system crashes whenever I try to run this product!  Why can't you write
software that works??!!"

"Thank you for your suggestion.  A copy has been forwarded to the developer
responsible for this component."

				-- Bob

Re: .22

To resolve misunderstandings like that, let the customer validate his 
call himself because he knows best.

"I have a problem and I want to have it solved now." 
   ( A problem call so, item 1 in reply .20)
                                          
                                  or

"I want to sugggest you an improvement but I don't expect further follow-up"
   ( A suggestion input so, item 2 in reply .20)

    
                                                 Henk
    

	re -.1 

	The IBM difference, similar answer would have a sentence :
	" Some of our best engineers are working to resolve this problem."
	
	[ maybe they wouldn't use word problem but rather, challenge or
	opportunity ]

	SPR status.
	Yes, customers did and still do report problems via SPRs but
	there is a more commitment to solve problems for contract 
	customer via support channels.

	CLDs.
	No, we don't have CLDs but we have CLDs. It's like Coke and
	Classic Coke. In the old time, a CLD was a qualitatively different
	from an escalated call, like a buss lane in a busy city.
	These were very serious problems from customer satisfaction point
	of view , DEC was on the line. CLDs got resolved very well.

	Now, CLDs changed status,  when corporate support went away,
	this is a way to escalate problems to corporate CSSE and Engineering.
	So, it's like an extra tag on P1 SPR or in some cases, equivalent
	to SPR P1. We got inflation in CLD process and lots of CLDs, 
	CLDs don't get resolved as quickly as before. So now, CLD is like a
	an extra priority in a long queue.
	
	This simply shows a basic flaw in change of CLD status, the problem
	is not that SPR P1 don't get resolved but magic CLD do, but some more
	fundamental organizational problems. 


	In real life, there is a need of "real" CLDs and we still have these,
	it's a call to VP or lots of unstructured pushing behind the escalation
	jungle.

		In any case , we welcome your challenges with enthusiasm and
		turn these to opportunities !


				...from European call factory

							wlodek
    

re .21 et al:

Having worked both in a CSC and as an Engineering group, I have had a good look
at the SPR mechnaism from both ends. The issue about "problem" or "suggestion"
isn't a big deal, as the system provides flexibility. The customer rates the
priority of the SPR from 1 to 5 (from memory) where 1 means "system down, I
can't do any work", and 5 means "this is a suggestion to improve the product".

This ties up with the traditional internal distinction between a bug and a
feature. According to this rule, a bug is when a product fails to deliver
what its specification (usually the SPR) promises; a feature is when a product
behaves unexpectedly but not contrary to the formal specification. Thus, a
customer might ring up and say "when my program does relative RMS access the
record pointer doesn't get incremented right" - then the question is, how is
RMS supposed to work in that situation? If the code doesn't deliver what the
SPR (or, often, the manual) promises, then it's a bug. However, if that is
documented or unspecified behaviour, it's a feature.

So if a customer sends in a priority 2 SPR, and it's determined that the problem
is a feature, the priority might get changed to 5 because the SPR now appears
as a suggestion (to change the documented behaviour to what the customer wants).
Needless to say, the customer has hardly ever read the documentation. In this
case, Engineering get a "suggestion" SPR, and the CSC takes resposnibility for
sorting out the customer's real problem (the program doesn't work as expected).
Usually this just involves a slight change to the code.

Notice that another important distinction has just appeared: the customer's
real problem is not always the problem he reports in the SPR. Common sense
suggests that Digital's task as a whole is to fix the customer's problem, not
just to implement his SPR! In extreme cases, the customer's problem can be
solved by an extremely simple workaround ("Did you know there's an RTL routine
that does exactly what you want here?")

In order to ensure that Digital always does the right thing with SPRs, there is
a formidable pipeline through which they get fed:

  1. The customer sends in an SPR (or the CSC originates one for him).
  2. The CSC "filters" the SPR to ensure it's not known or due to
     a misunderstanding. If so, they can return an early answer (e.g. "fixed
     in the next release").
  3. The SPR is sent to SPR Admin, who record it and forward it.
  4. CSSE record the SPR and check it out.
  5. If the SPR comes from Europe (or presumably GIA) it then goes to
     Corporate SPR Admin (and for all I know, Corporate CSSE).
  6. The SPR finally reaches Engineering.
  7. The relevant Engineering group deals with the SPR (earlier replies
     gave some detail about how this happens).
  8. The reply goes to CSSE, who check it for suitability. At this stage it
     can get shot back to Engineering ("You can't say 'Any fool knows this'",
     or "'Fixed in V5.7' is inappropriate: say 'Fixed in next maintenance
     release'").
  9. The reply goes to SPR Admin, who complete the records.
 10. The reply goes to the CSC, who forward it with a copy of the original SPR
     to the customer. Unless the reply is marked "not for publication", a copy
     is also placed in the database that is used to filter future SPRs.

Neat, huh? But open to some criticisms. First of all, because of all the
paper-shifting, the whole pipeline runs at the speed of the slowest section.
As we have seen, SPRs can take many months to come back. As a result, many
customers have stopped using them altogether.

Next, I have heard it said that every SPR costs Digital something like $5000
to process. Honestly, I can believe it. That's the cost of a workstation for
somebody! Granted, the process is vital, but can we do it faster and cheaper?

Maybe it's due to my bias, but I believe the answer is to do a thorough systems
analysis of the whole problem-reporting process, and then automate it. We
should also provide a simple utility with VMS and Ultrix which interrogates
a customer about a problem, and then spits out a standard (paper or electronic)
form. Customers have often told me that, from a standing start including
finding the form, it takes one person-day to fill out a paper SPR.

--Tom

    And lest one place too much confidence in customers being able to
    properly assign the priority of their problem, I am fond of showing
    people a priority 1 SPR I once received in which the complaint was
    "Since I installed a new version of VMS, I get an integer overflow
    when I run the game Dungeon."  My response was to try some more
    magic words.
    
    					Steve

    FYI, note 1504 in the NAC::ULTRIX notesfile has also recently been
    discussing SPR's and possible ["alleged"!] customer support problems.
    
    Jonathan
    
    PS. I have been following this conversation but still don't really
    understand the whole process very well...  This is probably to be
    expected, since,  being an internal customer, i haven't been exposed to
    how the "normal" customer interfaces with the corporation.  Also, as an
    internal "customer" i am even more confused with product notesfiles
    being the "official" mechanism for certain products, and the role of
    QAR's sometimes not only being for FT products... 

    Jonathan, you have every right to be confused.  One thing you may
    assume, however, is that notes conferences are not support mechanisms
    unless it is explicitly stated that they are.
    
    As for QAR bases, they are used in as many ways as there are QAR bases
    floating around.
    
    Marge

There is a problem with SPR response times.

Steve is right that some organizations give top priority to SPRs.
Some other organizations give top priority to SPRs most of the time or for
most products. The exceptions are sometimes just before a milestone on
the next version, or when the person with the knowledge is not available.

SQM publishs a report on SPR statistics.  It shows a problem.
I do not have a copy now, but I have a very strong impression from following 
it for over a year.

Almost all engineering groups have a long term trend of increasing backlog.
Many, (I think well over 50%), have not decreased the backlog during any
month of the preceeding year.  A substantial number of products
have a backlog and have not answered an SPR for 12 months.

There is a problem with SPR response times.

Re: .29  SPR backlog

Well, there's this hiring freeze....

As one who doesn't have any SPRs to worry about yet but who has a mountain
of QARs and just got my first CLD, all I can say is that I'm caught between
a rock and a hard place.  I hope I've found the right balance between adding
new features that people have been demanding in V2 while trying to fix all
the problems that have been reported in V1...

				-- Bob

    I recently had a conversation with the project leader of a neighboring
    development group, just before he left.  He told me that his group had
    not answered an SPR in many months, because they didn't have the
    resources to both answer SPRs and do the development work that they
    were committed to.
    
    I told him that if I were project leader of such a group, I would put
    enough resources on SPR responding to reduce the backlog to 0 in a
    reasonable time, and keep enough resources there to keep it from
    building up.  I would also tell my management that I did not have
    enough resources to do the development work.  If it took 3 months to
    eliminate the SPR backlog, with everyone working on it, then the
    "committed" milestones would be delayed for 3 months.  If my resources
    are so limited that the group can't get any development work done at
    all, because everyone's time is completely consumed by SPRs, then
    I would tell my management that all milestones were indefinitely
    delayed.
    
    I firmly believe that responding to customers' current problems should
    take priority over adding new features.  Maybe that's why I'm not a
    project leader.
        John Sauter

Re .31:

You might have enjoyed attending a meeting a long time ago where my cost center
manager observed that "We have signed legal contracts with customers to answer
their SPRs.  We haven't any contracts to deliver version n+1 to them".


Some backlog graphs disappeared from the Gray Book shortly after a certain
software development group firmly assumed the title of "largest SPR backlog in
Digital".  Must have been a coincidence.


One of the single most important aids to code quality I've ever benefited from
was reading Software Dispatches regularly.  If you think that reading code
teaches you how to write code, wait'll you see how reading bugs prevents you
from writing them.
				/AHM

> One of the single most important aids to code quality I've ever benefited
> from was reading Software Dispatches regularly.  If you think that reading
> code teaches you how to write code, wait'll you see how reading bugs
> prevents you from writing them.

  This was definitely true in the past.  Unfortunately, THE Dispatch
  (there's only one, right ;-) ) is virtually content-free these days,
  what with many of the bugs not being published and many of the pub-
  lished bugs having watered-down descriptions.  And reading "will be
  fixed in a future release..." doesn't add much information either.

                                   Atlant

Re .33:

Bingo.  I was sufficiently embarrassed that I haven't read any dispatch in over
2 years that I didn't want to claim that the sad state of affairs you describe
which was ascribed to one publication still prevailed today.

At least this gives every developer a more equal opportunity to commit the same
mistakes as their predecessors.
				/AHM/SIGH

    re: .32
    
    Yes, I would have enjoyed attending that meeting.  I would also have
    enjoyed working for that cost center manager.  I wonder if I did---
    I have worked for a lot of good people in my years at Digital.
        John Sauter

    re: .31
    
    Do you think that software engineers(/developers) enjoy fixing
    than creating software?
    
    Where do software engineers get their job satisfaction from?
    
    What do you think the healthy balance should be?
    
    Regards,
    Edwin

>     <<< Note 823.36 by NERSW5::OUYANG "Edwin Ouyang;LWO;(dtn)288-6650" >>>
>                             -< Fun versus Chore? >-
>
>    re: .31
>    
>    Do you think that software engineers(/developers) enjoy fixing
>    than creating software?

	As a 10-year veteran of writing applications code I can tell you I'ld
	much rather 'create' than 'fix' because 'fixing'  always
	means I did something 'wrong' in the first place (something I have a
	hard time dealing with).  
    
>    Where do software engineers get their job satisfaction from?
 
	Depends, but I can also tell you that there is a great satisfaction
	in 'helping' people out (even if it is 'your' code that's screwed up).
	Unfortunately too many Engineers take the quick/easy problems and
	produce solutions because you'll get instant gratification (but in 
	the meantime the *important* stuff is slid along).  Thus you witness
	the phenomena in NOTES files that Engineers provide answers to 
	questions though that medium and official SPR's are not answered.
	I'm not saying *EVERYONE* does this .... but it's prevelent enough
	to warrent attention and that is why I think Engineering is going to
	be measured in the future on open-time for CLD's & (I think) SPR's.
    
>    What do you think the healthy balance should be?
 
	I think an Engineering Dept. should recognise their responsibility to
	'FIX' problems via any means available (workarounds, updates, etc.)
	and PLAN for it just as they plan for new releases.  Rotate the 
	people though the different job functions on a monthly basis or 
	whatever but recognise the need to perform this support function.
   
	Chuck April CSSE/DECtp

    re: .37
    
    When I was a project leader (before CLDs existed) I was measured on SPR
    turnaround time.  Once when the statistics got screwed up and my
    product was reported as having an SPR that was over 365 days old, I
    heard from several managers above me.  I defended myself by pointing
    out that the previous month's report had shown no SPRs for my product
    more than 90 days old.
    
    I also wrote a nasty note to the department that was compiling the
    statistics.
        John Sauter

    In some software groups, there's one or more persons assigned to
    maintenance (e.g., about one person per 300K lines according to one
    senior manager in New Hampshire). I think that encourages a
    throw-it-over-the-wall mentality. If you're backed up with so many SPRs
    that you don't have time to work on new interesting stuff, you can be
    damned sure that a lot more thought would given to making the new stuff
    more easilly maintainable and right the first time. I've seen source
    listings of drivers and other code authored by some Digital's revered
    geniuses that could write hundreds of lines of code a day -- and there
    were a long list of names (an army) of people listed that had to clean
    up the bugs over the years. I think people should clean up their own
    messes. A software engineer shouldn't be allowed to work on new
    software until the SPR rate falls to one moderate impact bug per
    six months.

Food for thought --- the obvious isn't always obvious.

The "fix every bug first" theory has its opponents in computer science:

IBM published a paper, for example, that argued that, in general, bugs
should NOT be fixed unless they are reported a minimum of two times.

(Obviously there is a class of serious bugs that does not fall under
this rule).

In part, they argued that they could demonstrate statistically that
for large programs the odds of introducing a new (and often more
serious) bug was greater than the odds of a clean fix unless the bug
was being observed by a sufficient number of users.

(They didn't explain why number-of-times-reported should bear any
corelation to the quality of the fix, but they didn't really have to).

Note that this was a statistical argument that can't be easily
defeated with discussions of how the world "should be" --- they
were simply reporting the way it really is.

Of course, one can always fall back on the "lies, dammed lies,
and statistics" theory, but ....

- greg

ps: BTW, there are also studies that suggest that no amount of
    effort can reduce the bug reporting rate below a certain
    threshold.  As you fix 'em, customers just find and report
    bugs from other layers/levels --- often reporting things
    they would not have bothered with before.  There is a point
    at which the ROI of bug fixing reaches diminishing returns.
    Some suggest this reflects a pragmatically "infinite" bug
    pool in any complex system and reducing it to zero is a
    [who was the mythological character that had to roll the
    boulder up the hill?] type task.

re: .41

Thanks, and how appropriate the answer should come from Aristotle ;-)

- g

Re: .37

>	Unfortunately too many Engineers take the quick/easy problems and
>	produce solutions because you'll get instant gratification (but in 
>	the meantime the *important* stuff is slid along).

Given a choice between fixing 20-30 quick/easy problems or spending the time
trying to reproduce 1 or 2 high priority ones I'll often choose the quick/easy
problems, not because I want "instant gratification" but because in some cases
it may be a more efficient use of my time.  I try to use my best judgment in
each situation.

>	Thus you witness
>	the phenomena in NOTES files that Engineers provide answers to 
>	questions though that medium and official SPR's are not answered.

I've done that (almost); I answer questions in notes files even though I
have a QAR (not SPR) backlog.  I assume that if someone asks a technical
question in a notes file that I'll be helping DEC in some way if I answer
the question.  If the problem would take more than 15-30 minutes of my
time, though, I usually ask them to submit a QAR.

>	I'm not saying *EVERYONE* does this .... but it's prevelent enough
>	to warrent attention and that is why I think Engineering is going to
>	be measured in the future on open-time for CLD's & (I think) SPR's.

I've answered the handful of CLDs and SPRs I've received within a few days,
but if I start to be measured *only* on the open-time for CLDs and SPRs then it
will be time to find a new job.  Currently my management seems to be more
interested in meeting schedules.

Getting rid of my QAR backlog is high on my list of things to do, but it
isn't the only thing I have to do.

				-- Bob

    re: .37
    
    Thanks for your quick reply, I held up the last question which was
    on my mind:
    
    Do you think the managers of software engineers check into this 
    topic so that they could benefit from this discussion, so would 
    the company eventually?
    
    
    Regards,
    Edwin 

	At least one manager of software engineers has replied to this
	topic. As I've seen several other reply in other topics in this
	conference I would have to assume that other managers of software
	engineers are reading this topic. How much they and the company
	benifit is anyones guess.

				Alfred

Re: .44
    
>    Do you think the managers of software engineers check into this 
>    topic so that they could benefit from this discussion, so would 
>    the company eventually?

Actually, my manager is one of the moderators...  I don't know how
closely he tracks the conference, though.

				-- Bob

    Up to 6 or 7 years ago, there there was a technical support group that
    answered SPRs (and handled phone calls, and did maintenance releases)
    for the 36-bit software. Then those people were, for the most part,
    merged into the software engineering group, so that the same group had
    the role of developing new code and maintaining existing code. Some
    observations from a person who lived through that period:
    
    While it existed, the TSG was *the* place where SPRs were handled.
    The customer, with or without the help of a local DECie, formulated and
    submitted the SPR, and after the interminable delay through SPR admin,
    it came to the TSG. It was answered in that group. Any code changes,
    work-arounds, suggestions to modify applications, requests for more
    information, or any other steps necessary to close the SPR were performed
    by that group.
    
    The obvious advantage of having the TSG was that their prime objective
    was to keep the SPR backlog to a minimum. It was almost exclusively
    the yardstick by which they were measured. There was clear incentive to
    turn around SPRs as quickly and accurately as possible.

    Fixing bugs was also an excellent way to become technically proficient
    with a product, and thus the TSG people were usually effective
    telephone support people too.
    
    The obvious disadvantage was the promotion of a "throw it over the
    wall" attitude, as mentioned in a previous reply. Also, developing and
    maintaining different versions of the code, in different groups with
    limited interaction, inevitably led to inefficiency in merging the
    maintenance edits into the development code, and occasional situations
    where a problem was fixed in version n.m and broken again in n+1.0.
    
    Then it was deemed fitting that the TSG be merged into engineering.
    About 30% of the TSG's work, telephone support, went to a group in
    Colorado know at the time as the TSC (telephone support center).
    Some time between then and now, TSC turned into CSC, started
    front-ending SPRs, and CSSE came into the picture to further screen the
    problem reports.

    The immediate advantage to merging TSG and engineering was that everyone
    was working on the same code, so it was much easier to merge
    maintenance and development work. Also, fixes to existing problems
    could be implemented with an eye toward future development, rather than
    in spite of it, which had often happened in the past.
    
    The big disadvantage was that each engineer had two responsibilities,
    development and maintenance. Unfortunately, emphasis was often placed on
    the development responsibility, to the detriment of the maintenance
    responsibilities. Like testing, maintenance will most likely take a
    back seat when the crunch is on.
    
    Another disadvantage was that we lost an excellent training ground for
    the people who provide telephone support to customers. I have the
    impression that the learning curve for telephone support people is a
    long and painful one, mostly because they to not have the opportunity
    to get their hands into the code.
    
    One thing that has not changed is the gross inefficiency and built in
    delay of the SPR (Seldom Produces Results) system. I have never been
    able to figure out why a company that prides itself on network
    management insists on a hierarchic approach to SPR management. They
    seem to all be sent to one office, and then trickle down for weeks
    or months (or even years, if persistent rumors are to be believed)
    until they finally hit the right people.

    Lately, it has become painfully apparent that the multiple levels of
    screening can inject a tremendous delay in the closure of some SPRs.
    As far as I can see, CSC and CSSE can only turn around the SPRs that
    don't require product modification; the rest MUST come to engineering,
    but only after the first two levels of screening, which may take some
    time in the less obvious cases. And lest people take this as a rail
    against CSC and CSSE: I know first hand that there are people in both
    groups working their hoofies to the quick to maintain customer
    satisfaction. There is strong indication, however, that the current
    multi-level structure impedes their progress.

    Suggestions based on these observations:
    
    Customer telephone support, product maintenance and product development
    should all be done within a single group. This approach will be necessary
    to keep people up to speed in complex and dynamic environments that demand
    immediate support for customer problems (TP, for example). Inductees could
    spend a time answering SPRs to get familiar with the product, then include
    phone support responsibilities, and then various levels of development.
    
    SPR backlogs should be a prime consideration in the phase review
    process. Backlog goals should be established in phase 0, and should be
    monitored in the phase 2 and phase 3 passages, and by SQM in their
    interviews.
    
    The SPR system should be entirely electronic. A customer should be able
    to dial in an SPR, with a code (provided in the software license) that
    delivers the SPR immediately to the right software group. A central database
    can be maintained for statistics and customer queries.
    
    Re: .37
>>	Unfortunately too many Engineers take the quick/easy problems and
>>	produce solutions because you'll get instant gratification (but in 
>>	the meantime the *important* stuff is slid along).  Thus you witness
>>	the phenomena in NOTES files that Engineers provide answers to 
>>	questions though that medium and official SPR's are not answered.
>>	I'm not saying *EVERYONE* does this ...

    It is really unfair to assume that the easy ones get answered first,
    or that NOTES questions get answered before SPRs, for reasons of
    instant gratification. The easier ones get answered first because...
    they're easier. It is only human nature to get the easy tasks out of
    the way first, or break up a hard one with some easy ones. Easy SPRs
    get answered quickly; hard ones take time. Easy NOTES questions get
    answered quickly; hard ones sometimes never get an answer.

>>	                                 ... I think Engineering is going to
>>	be measured in the future on open-time for CLD's & (I think) SPR's.
    
    An interesting comment. As far as I know, CSC, CSSE and engineering all
    have some level of responsibility to close problem reports, but the
    buck stops at engineering and engineering will be measured on how they
    are closed. I believe I'll take that as another argument for bringing
    all people responsible for technical support of a product into one
    engineering group. If I had final responsibility for how long a CLD or
    SPR remains open, I'd surely want to control the process from beginning
    to end.

    I'm not sure it would be practical to merge the telephone specialists
    for a product with the development engineers.  While that would
    concentrate responsibility, it would not erase the fact that these two
    jobs require quite different skill sets, and the telephone specialists
    need a very special physical plant to handle calls efficiently.  Also,
    both developers and telephone specialists benefit from being around
    their counterparts in other products.
    
    I think it might be more practical to simple establish, and maintain,
    good communication between the groups working on a particular product.
    NOTES and MAIL are good ways to do that.
        John Sauter

    
>    I think it might be more practical to simple establish, and maintain,
>    good communication between the groups working on a particular product.
>    NOTES and MAIL are good ways to do that.

        John Sauter,

	Good point !  And as one of the CSSE people in "Wild Bills'" 
	description ("workin' their hoofies off") I am attempting to 
	come up with a contract that will be the basis for communications
	flow from the Customer down through to Engineering and back that
	will make use of NOTES & MAIL but on a formal basis rather than
	this informal network that has sprung up.  If it works out well,
	look for a similar introduction for other products that I plan
	for (DECforms, TP monitor, etc.).

	Chuck 

	P.S. ( I used to fix the easier problems too Bill !  I loved it
	       when I would get the 'Guru' pats-on-the-back for fixing
	       one line of code. Your right, it's human nature ... but
	       that's why we have managers .... to keep us in line. ) 

    
    Re: .47
    
    Thanks for your informative SPR observations which I enjoyed reading.
    
    Some feedback and questions about your suggestions:
    
>    Suggestions based on these observations:
    
>    Customer telephone support, product maintenance and product development
>    should all be done within a single group. This approach will be necessary
>    to keep people up to speed in complex and dynamic environments that demand
>    immediate support for customer problems (TP, for example). Inductees could
>    spend a time answering SPRs to get familiar with the product, then include
>    phone support responsibilities, and then various levels of development.
 
    As above, in a single group, the new-hand (new to the whole process) would
    begin with answering SPRs, then do phone support, and then get into
    various levels of development.  Then, how big should this group be, or
    what would be the ratio of people working in different functions?
    How long would each people stay in each function? Regarding the
    morale of the group, how to ensure people doing the fun stuff also
    share the chores at the same time, how to motivate them? Should
    the group work in the same location and eat in the same cafeteria?
    
    On the other hand, I see the old-hand can answer SPR's much more
    effectively. If competitive SPR response time is truly considered
    as high-priority company goal, the old-hands must be motivated to
    share the SPR-answering responsibility, coaching the new-hands may
    be a good start.
     
>    SPR backlogs should be a prime consideration in the phase review
>    process. Backlog goals should be established in phase 0, and should be
>    monitored in the phase 2 and phase 3 passages, and by SQM in their
>    interviews.

    People in the group answering SPRs would like this more than people
    doing development, because they can feel the results of their work
    getting attention and visibility. If the old-hands get involved
    somehow, then they could also sense the satisfaction somehow.
           
>    The SPR system should be entirely electronic. A customer should be able
>    to dial in an SPR, with a code (provided in the software license) that
>    delivers the SPR immediately to the right software group. A central database
>    can be maintained for statistics and customer queries.

    I agree totally, it's much healthier (in many ways) to read a
    problem than to hear (listen for trained ears) a problem. I did
    telephone support, so I understand how it's like working on the
    phone in CSC, it could be very hard on your ears. Besides, following
    the old wisdom, "you hear you forget, you see you remember, you
    do you understand", reporting a problem into a SPR database for
    the right people to see/read is the more effective way of communicating
    the information to the developers.
    
    However, the urge to talk to a real person when reporting a problem
    should not be ignored, how to address that (customer satisfaction)
    need while using the SPR database by the customers, needs some work.
    Ensured consistently good response time from experiences may reduce 
    the intensity of that urge gradually, if not totally.
    
    Furthermore, as any database, the SPR databse can only be as good as
    its contents.  The common sense, "garbage in, garbage out" fits
    here, especially for information about bugs, some information may
    be critical in time for a while now, may become superfluous shortly
    after.  The quality/value of this SPR database replies on the quality
    of its maintenance.  Maybe people experienced in the SPR database
    in the past could share some of history/wisdome here.
    
    Regards,
    Edwin
     
    

    My personal view is that the separation of maintenance and
    development leads to deficiencies on both sides.  I'm a firm believer
    in an engineer doing both, and I actually enjoy tracing down and
    fixing bugs - it gives me an immediate sense of accomplishment and
    I know I can make at least one specific customer happy.  It also
    gets me to look at and understand a part of the product I might
    not otherwise have seen yet, and that helps my development efforts
    because I now understand more of the interactions in the code.
    
    Engineers who do only new development can lose touch with what the
    customers are doing and the problems they are running into.
    People who do only maintenance miss out on the opportunity to create
    something new, something that is their own. 
    
    I don't have a good solution to the general problem, but anything we
    can do to give the support people more of a feeling of "belonging"
    in the products they support will be an improvement.
    
    It was a delight to me to spend a day at the CSC in April, while I
    was on vacation, to sit on the phones for a while, and to talk to
    the different support people.  It gave me a whole new understanding
    of what goes on out there. 
    
    				Steve

    re: .51
    
>        My personal view is that the separation of maintenance and
>    development leads to deficiencies on both sides.  I'm a firm believer
>    in an engineer doing both, and I actually enjoy tracing down and
>    fixing bugs - it gives me an immediate sense of accomplishment and
>>   I know I can make at least one specific customer happy.  It also

     You actually make all customers using that product happier, even
     they haven't been burned by the bug yet, and hence increase their
     confidence in Digital and will buy more from Digital rather than
     from say, IBM.
    
>         It was a delight to me to spend a day at the CSC in April, while I
>    was on vacation, to sit on the phones for a while, and to talk to
>    the different support people.  It gave me a whole new understanding
>    of what goes on out there. 
    
    It's good you did sit on the phones for a day, so you could understand
    half of the process.
    
    To understand the other half, try go onsite with support people,
    working til 5 or 6 a.m. and customer's people coming in at 7 or 8 to
    use the system, never mind the lack of familiar resources you have in 
    your office...,I can continue on with more, but as mentioned earlier
    "... you do you understand", so I'll stop but just to point out
    there's the other half, most people don't see including some holding
    the phone on the other end of line and some managers in support. 
    
    Let's go back to topic on SPR's.
    
    Regards,
    Edwin                        
    

    
    re .51
    
    > Engineers who do only new development can lose touch with what the
    > customers are doing and the problems they are running into.
    
      I don't really understand why a person would not want to make sure
    that their software was a quality piece of work.  I mean, if I spend
    six months working on an application system for a customer (I used to
    do pss), I really want to know about all bugs in that software.  It
    used to drive me *crazy* when they would assign someone else to 
    "mess with" my code.  Also, I wanted to know what was it that I did 
    wrong, so that I would not make the same mistake again.  A lot of times
    it would turn out that the specs didn't jive with what they really
    wanted, or I had not understood some nuance of what they wanted.  A
    person can learn a great deal and also grow professionally when they
    review their own code for bugs, say, a year after they wrote it.  
    
    Could someone who writes code, but hates to fix it (I mean the code
    that they themselves have written) please enlighten me?  I mean,
    what is so %&*-awful about maintenance?
    
    jc
    
    
    
    
    

    The guy  who  posted  the original note on the Usenet has posted a
    new  version. It doesn't seem to have changed much. He asks in his
    latest posting if anyone at Digital will respond.

--David

    I do not believe he wants a serious answer from DEC. I really do
    not believe it. If he wanted an official answer he would work
    it through his local sales people or failing that he would send
    KO a letter directly. I believe 100% that all he really wants
    is some DECcie to say in public "Yeah DEC doesn't care about SPRs".

    I mean really now. He knows how to contact DEC directly or he could
    not have filed all those SPRs. He must have an address for SPR
    administration right? He must have a name and phone number of his
    local DEC sales support people. If he really wanted an official
    answer he has to know that those channels will react faster then
    USENET right?

    			Alfred

    re: .55
    
>    					If he really wanted an official
>    answer he has to know that those channels will react faster then
>    USENET right?
    
    Isn't this the substance of his beef, though?  He claims to have
    sent numerous SPR's through "official channels" and further claims
    that they are not acknowledged a large portion of the time.  Is
    it not possible that one who has lost faith in the "official" complaint
    conduit (SPR admin.) might seek relief through unofficial channels?
    
    I know nothing about the person in .0.  Whether he is serious about
    a response is entirely unknown to me.  But his current actions (via
    USENET) do not seem entirely out of sync with his claimed experience
    ("SPR's don't bring responses").
    
    Just a thought...
    
    -- Russ

    re: .57
    
    For the record, I agree with you 100%.
    
    I, for one, would gladly correspond with responsible parties in St.
    Louis if someone could manage to get me the name of a Sales Rep
    or Sales Manager who might be responsible for the account (if someone
    nearer to the account would like to take care of it, that would
    be great -- but it needs to be dealt with).
    
    Anyone out there have an idea of whom to contact?  You can send
    me mail at NEWVAX::PAVLICEK.
    
    -- Russ

    I've placed a call to the STO office.
    
    Someone at STO is attempting to determine the appropriate party.  I
    will forward the information as soon as I have a name or MAIL address.
    
    -- Russ

    
    There may still be such a thing called:
    
    Customer Assistance Desk
    
    In NorthEast Area, the number is: 1-800-222-8114, from the card
    I am reading; you may find it in your area. 
    
    Regards,
    Edwin

    I've forwarded the message contained in .0 to someone assigned to
    the account.  He had never heard of "Arthur B. Smith", as shown
    on the header.  He couldn't find the name in the University phone
    book, either.  He is investigating the matter.
    
    -- Russ

Re: .57

    Several Digital employees are among the many people who respond to
    questions  posted  on  the  Usenet bulletin board in question. The
    bulletin  board  is  the  equivalent  of  a notes file. It's often
    faster  to  get an answer from the informal electronic medium than
    to  try  to  figure  out  what the official channel is. As long as
    that's  true,  people both inside and outside Digital will use the
    informal media.

--David

    Creating organizations (e.g., an SPR fixing group) is treating the
    symptom rather than the problem. The SPR problem will only increase as
    more new software is generated.
    
    If one wants to make the SPR response/fix times competitive, the
    software developer must be goaled and measured on two things: 1) more
    emphasis on fixing bugs than getting new product out the door, and 2)
    more emphasis on design for quality software than getting to the coding
    phase.
    
    It is wishful thinking to ever think that Digital's managers will goal
    their developers more on quality than getting something new out the
    door. Managers are very concerned about image. A large number of bugs
    to be fixed implies a bad job of producing a quality product, i.e.,
    something a manager doesn't want to make highly visible. Managers don't
    want to tell their bosses that their key deliverable will be fixing
    bugs. Managers would much prefer to show their bosses that they can
    "deliver on schedule".
    
    Managers can move the "quality problem" out of their group to another
    group (a maintenance group or maintenance persons within the
    development group). Having maintenance people also institutionalizes a
    continuous stream bugs (SPR reports) on a product as being acceptable.
    There's nothing akin to manufacturing's statistical quality assurance,
    nor anything akin to zero defect manufacturing in software.
    
    On the bright side, we'll see more use of analysis/design tools,
    prototyping tools, code generators, higher level languages (like
    C++) to do what was previously done in assembler and BLISS. This will
    reduce the number of bugs per hundred thousand lines of code.
    
    WIMP (Window-Icon-Menu-Picture) interfaces to software will allow
    more intuitive programs to be written, resulting in less need for
    manuals and submitting SPRs where a there is no real problem other
    than finding the informantion. Also, hypertext technology with
    on-line help and bookreaders will make finding the information
    easier, reducing the number of bogus SPRs.
    
    On the dark side, the total number of lines of code is growing as fast
    or faster than use of new technology to bring the bug rate down. Due
    to the lack of goaling and measurement on quality, the number of
    SPRs will likely continue to grow, and the response times to become
    even worse.
    
    -George

I work with the group at CSC/CS which has been responsible for screening VMS
and many 32 bit layered products during the past several years.

This note was brought to my attention today, and when I forwarded the issue to
my manager, Sue Clavin, I discovered she was already aware of the issue, and
is pursuing this with SPR Admin, and will eventually communicate with the
customer, if we can obtain a real name and phone number. We assume we can from
the information submitted with the SPRs.

The SPR process has had lots of problems in the past, almost all concerning lack
of sufficient resources at all levels to handle the volume. In no cases, have
I encountered any group or individuals within Digital, who have shown a lack of
concern for doing the right thing for customers. However, the lack of resources
has almost always created a bottleneck in which it is difficult to get the right
information about a problem to the correct group/individual in a timely fashion.
If we can ever solve this information flow satisfactorily, then I believe we
will make progress.

One of the issues raised in an earlier reply concerned written communication on
problems vs oral communication. There are pros and cons to both sides.

Originally, all communication on "SPRs" was written. This was useful when the
customer took the time to be complete and supplied all necessary information 
with the written form. However, if the customer was not complete, then it some-
times took several iterations of written communications between the customer and
Digital, until there was sufficient information to work the issue. A little over
three years ago, we at CSC/CS decided to eliminate this non-productive delay,and
talk to the customer on the phone when we needed more information. We had the
phone facilities, and in most cases this worked well. When we needed large
amounts of information, we could tell the customer what we needed, and they
could then package it and mail it directly to us. In addition, when many of the
formal responses to issues were " This is fixed in the next release...", then
it was decided that this information could be given to customers in a much more
timely fashion via phone, rather than in a written communication. For many 
customers this has worked well. However, for some customers, written communica-
tions are prefered, either because the issue is complex, or because of there own
internal problem tracking methods. In addition, a written response from Digital
may be prefered if it is difficult to get hold of the customer via the phone.
Also, written communication, when well done, leaves no room for issues of "you
didn't tell me that...", either on the customer side, or on the Digital side.
Written communication provides an audit trail which is difficult to capture in
oral communications. As we gained experience in these issues, it became
obvious that there was very little difference between a phone call to a CSC and
an SPR. As long as we maintained a mechanism to escalate real bugs to Engineers
then it really didn't matter whether the customer told Digital about an issue 
using a phone call, or using a piece of paper. We have therefore been working
very hard to integrate this business.

There are times however, when written communications are useful. A well written
problem report on a complex issue may be much easier to understand than an oral
report. Therefore, CSC/CS had a group of people develop an application which
would allow us to communicate directly with customers over dialup phone lines.
This software is currently in field test, and if all goes well, will be deployed
to at least some customer sites during the next fiscal year. This should allow 
us to have the best of both. Customers can send us "written" communications 
efficiently, and we can respond either in a written form or by phone when 
appropriate.

The SPR channels may not appear to work as efficiently as one would hope, but
all organizations in the chain are aware of the issues, and are expending effort
to identify problems and get them resolved.

re: .64

You raise an important problem in your note.

>The SPR process has had lots of problems in the past, almost all concerning lack
>of sufficient resources at all levels to handle the volume. In no cases, have
>I encountered any group or individuals within Digital, who have shown a lack of
>concern for doing the right thing for customers. However, the lack of resources
>has almost always created a bottleneck  

Concern is one thing, spending money is another.  Somewhere between you
and Ken Olsen, a decision was made not to acquire sufficent resources to
do the job.  Feeling concern for the customer's problem may make the customer
feel better, but it doesn't put food on the customer's table.

Feeling sorry won't work; what can we do to solve the problem?

Martin.

    Hate to get in the middle of official works, but the original Usenet
    poster repeated his message on 21-JUN stating that nothing has changed.
    
    I sent him a short message asking for more info. (phone # primarily) so
    that we can look at his specific situation, and asking if he had been
    contacted by anyone else from Digital.
    
    He responded within 10 minutes with what looks like a very detailed
    description of his work, his sales people, the spr's, etc.  He also
    said he received one other Digital response giving sympathy and
    assurance, "but little more".  
    
    A few questions:  Did anybody finally manage to track him down?  Will
    the info. he sent be useful to those trying to do something more?
    
    Below is part of his message that looks non-confidential (if it's not,
    then feel free to hide this note.. as always.)
    
    jjd
    -------------------
List of unanswered (acknowledged) SPR's:
 
Date		Corporate SPR #		SPR Serial #	About
05/18/88	ICA-16137		488066		vcc
06/10/88	ICA-16812		486302		SPR's
07/01/88	ICA-17592		488070		getopt
08/01/88	ICA-17595		488072		dump
10/04/88	ICA-19272		495368		cc
10/27/88	ICA-19267		494568		math.h
10/31/88	ICA-18208		494551		who,utmp,mail
11/16/88	ICA-19682		492864		mktemp
12/20/88	ICA-22163		499573		setsockopt
12/20/88	ICA-22241		499161		tcp_nodelay
04/03/89	ICA-22185	       1091962		mail
05/17/89	ICA-19268		488076		listen,connect,accept
05/18/89	ICA-22911		715649		getpwent
05/30/89	ICA-22938		713957		sizer
 
Unacknowledged SPR's:
 
12/20/88	  --			499575		Phone SPR's
01/23/89	  --			499162		types.h

I have checked our TIME database for some of the SPRs listed here. The ones I 
have access to are ULTRIX SPRs. This matter will be refered to SPR Admin and
ULTRIX Engineering.

    re: -.1
    
    thanks... I have also heard from the sales contact for the customer's
    location and he assures me he will contact the customer...
    
    fwiw - i believe one reason for some previous confusion was that the
    address the Usenet message was posted from was different than the
    customer's actual location.
    
    
    now back to the general... i gather from these replies that we've
    concluded that we are recently trying to improve customer satisfaction
    in a few specific ways.  glad to hear it!
    
    jjd