Conference 7.286::digital

    Re. .0
    
    I don't disagree with anything you have said. However, I believe, and
    quite strongly, that:
    
           You Get What You Reward.
    
    A lot of people don't want to hear that. But it's true. I don't want to
    ramble on about metrics again. But it IS true. And yes, we have mostly
    ourselves to blame for much of our pain. 
    
    Gene.

    The market is in Systems Integration.  
    
    FOLLOW THE MONEY!    Plain and simple...........................
    
    What are companies spending their money on?
    
    What influenced those spending decisions.
    
    Satisfy the customer need, and we'll make our numbers.
    

    I disagree with a lot of� what you have written here.

    The immediate cause of "Digital's slump" is a failure to execute the
    strategies that were announced to customers in 1990 and 1991.  If you
    want to reduce this to "time to market", then be my guest.  We talked a
    good talk.

    �A recession?  Apple, Cray, Sun, Compaq, Hewlett-Packard, Data General,
    Intergraph, and Amdahl were profitable.  IBM which was unprofitable in
    calendar 1991 was profitable in the first calendar quarter, as was
    Unisys.

    What sort of worldwide economic recession is it that hits Digital
    harder than Unisys?

    "By any measurement you might choose..."  Such puffery undermines the
    rest of the paragraph.  If we're so smart why aren't we rich?

    "We began to believe the press..."  The "press" is a convenient thing
    to blame.  The press didn't create this problem.

    We created this problem where we promised open systems and didn't
    deliver.  We created a credibility problem around our commitment to
    UNIX.  Self-inflicted.  Customers want the Digital of 1992 that we
    promised to them in 1990, not the Digital of reality in 1992.

    If you think that customers respond to the "hard sell", you are
    mistaken.  Customers respond to value.  Wrapped up in value is what
    vision of computing does the vendor have and what is their fidelity to
    that vision.

    Your history of the last three years is so full of error that I can
    hardly believe that we work for the same company.  In my experience,
    our UNIX _systems_ offering was incomplete.  We were always hearing, you
    can do that in VMS but not UNIX.  That's not ported yet.  That requires
    a server that runs VMS.  UNIX was a neglected child to alude to a
    famous analogy I heard once.

    Many customers don't have sympathy for those sorts of problems.
    Many customers are accepting a "good enough" UNIX or DOS solution while
    conceding that VMS might be better in a narrow technical sense.

    For the most part the criticisms� of Digital as not taking notice that
    the minicomputer and terminal was no longer the focus of solving
    significant computing problems, personal computers, UNIX workstations
    and servers were becoming more important.  The growth of Sun and
    Hewlett Packard reflect this sweeping environmental change that Digital
    could speak to but never could match in the nitty-gritty of products
    and sales tactics.

    The potential "up for grabs" UNIX workstation and server business is
    billions and billions.  The IBM 9370 and AS/400 business for the most
    part is momentum driven by legacy applications.  We win more of that
    business based on dissatisfaction with the incumbent vendor that we do
    on product "merits"

    You are honest in denying that there is a UNIX market that needs to be
    addressed with a "no compromise" UNIX strategy.  A lot of people don't
    write with the clarity you do.

    There is a UNIX market.
    There is a UNIX market because there is a group of people committed to
    the idea that UNIX is op�en, UNIX has applications, UNIX has the best
    software development tools.
    
    These people are not Sun employees, they are our customers, or we hope
    to make them our customers.

    There is a DOS market.
    There is a VMS market...

    Real customers know enough about there problem to specify the operating
    system they want.  It's nothing more than disrespect to convince them
    othewise.  OK, sometimes it's arrogance.

re...0

A very eloquent piece indeed but I got turned off by the
"hard sell" undercurrent, and from my experience with customers
from 10 years in the field, they'd be turned off too.

Hard Sell implies = a callous disposition = take it or leave =
a put-down, like, if you don't know that this is a good deal then
tough luck for you  = I got only so much time to spend with you,
so make up your mind quick.

Being good at customer solutions means, being first interested
in people and patient enough to lend them your ear so that you
can take in 'the whole story';  and this takes
{some} time and time = resoures (such as how much selling and how much
fixing you can pack into one day. But it's all part of, and based on,
building up relationships - lasting relationships - and that's
based on trust - and trust is the basis for all success, whether
business or personal.
The Hard Sell concept reminds me of a doctor who first checks
your insurance coverage instead of stopping the bleeding.

Digital still has to learn that you got yo maintain and tune a car
before it'll take you anywhere. We typically talk 'acceleration specs' (call
it ROI metrics and all the rest) even before we turn the key.


rrrrrrrrooommmm, rrrooooom, roooommmmmmmmmmmmmm, mmmmmmmmmmmmmmmmmmmmmmm,
Karl


p.s. on 0.3;  "your bell has a warmer ring to it than 0.1's"

    The following is from the head of Computer Operations for a National Lab.
    (He was asked by management to address a crowd of approx. 70 Digital people
    and include "things Digital could improve."  He told us - yesterday - he
    polled dozens of his people; the following is listed in order of 
    responses.  His quotes are included from my notes)
    
    1.  High price of peripherals.  ("Always been true, especially in
    disks.")
    2.  CPU price/performance ("It's gotten embarassing to buy DEC")
    3.  High cost of technical support ("We did a cost/return analysis, and
    the DEC support costs stick out like a sore thumb.")
    4.  Lack of "real" non-dislcosures (mentioned they would read about it
    in the paper the next week.)
    5.  Software licenses ("want smaller granularity/increments")
    6.  Billing practices ("Sometimes we'd get 4 invoices on the same
    order!")
    7.  Packages that are more expensive than buying pieces ala carte ("We
    then became suspicious and cost-compared all of DEC's packages.)
    8.  Availability of sales people ("This is somewhat dated because we
    think it has gotten better lately.  But we used to write their names
    in pencil because they changed so much.  Frustrating.")
    9.  Delays in hardware deliverables (no specifics given)
    
    He mentioned others, but they were not germaine to the base note.  What
    struck me is that NONE of his "complaints" were about product
    performance.  The things he mentioned were pricing/policies/practices/
    trust/support things.
    
    *I* think most of our problems are self-inflicted and systemic in
    nature.

    I wonder sometimes if we tolerate screwups, lack of focus, customer
    insensitivity and other problems in the name of "valuing differences".
    I'm certain this would conflict with the intent of the program.  But, I
    can't understand why we continue to tolerate rebuffing customers.  I've
    heard stories like -.1 for at least the past five years or so.
    
    Steve

    Re .0:
    
    > By any measurement you might choose, Digital Equipment Corporation
    > has the best products and services in the industry.  We also have the
    > best talent, in engineering, in marketing, in services and especially
    > sales and support.
    
    By no means does Digital have the best products.  Digital's operating
    systems are in shambles.  I've worked on both Ultrix and VMS, and
    internally they are a mess.  Digital has never enforced proper software
    engineering techniques, so the code has degenerated into an
    unmaintainable, incomprehensible mass of spaghetti.  I tried to write a
    test program for the math library only to find that the C run-time
    library can neither read nor print all the bits of a floating-point
    number.  The Ultrix source code is replete with comments like "XXX",
    "I'll bet it won't work!", "WARNING: this is half-baked and
    incomplete", and so on.  VMS is similarly confused.  Both Ultrix and
    VMS have masses of pending problem reports they cannot hope to catch up
    on.
    
    Digital's hiring "freeze" means Digital has not been hiring new college
    graduates.  Every day that continues means Digital slips further behind
    the state of the art.  New blood and fresh ideas are not coming into
    the company.  Nor does Digital do adequate basic research to keep up.
    
    Hardware is no better.  How can Digital have any self-respect when it
    buys computers from Tandy and resells them?  I recently saw a 9600-baud
    modem Digital makes -- it was huge, around nine inches by five inches
    by three inches.  For comparison, I have a PC-compatible made by
    Hewlett-Packard.  It includes a megabyte of RAM, a megabyte of ROM, a
    plug-in card slot, Lotus 1-2-3 in ROM, an RS-232 port, and more.  This
    entire computer is smaller than the AC adapter for Digital's modem. 
    When I connected the HP-95 to my DECstation 3100, I had to reduce the
    95's baud rate because the workstation port only handled 9600 baud. 
    (The battery-operated PC can go to 19,200 or 57,600.)
    
    Once, I thought Digital could catch up.  But it takes an investment of
    time and resources to do that.  Digital would have had to forego the
    short-term profits of a release in order to spend time redesigning and
    rewriting the software, using proper quality controls.  The result
    would have been software that is more understandable, easier to change,
    and had fewer bugs.  It would have paid off in the long run. 
    Similarly, Digital needs to hire new talent.  It needs to invest in
    basic research, so that it can build new hardware before it falls
    behind the rest of the industry.  Alpha is late; it won't be a
    technology leader.  After all, it is Digital's third attempt to build a
    new architecutre -- the first two failed.  Once Digital could have
    caught up.  Now, Digital might be too far behind.
                                                         
    
    				-- edp

    
    Re: .7
    
    I don't often agree with EDP, but with respect to his comments about
    the state of our operating systems and lack  of controls on the
    development process, he is 110% correct.  That's the bad news.  The
    good news is that David Stone knows this and has made developing a
    world class software development process that produces products that
    delight our customers one of his highest priorities.  Stay tuned.
    
    Steve
    

    Re .7

    How do we compare with the competition? It must be nearly 20 years
    since I wandered round the inside of an operating system (Scope for CDC
    on a 6600) and it was exactly as EDP described it, a collection of
    patches and bewildering comments. The other operating systems that I
    worked on before that were also very messy. It seems to be their nature
    as they are living entities and constantly changing.

    So are our competitors operating systems better? Has anyone out there
    got the experience who can tell us

    Jamie.

.7 is absolutely my experience as well.

But, it's even worse than that.  Aside from having sources that are in shambles,
and having no short or long term plans to correct that (I've personally had a
project plan turned down when I asked to re-engineer some software to make it
more robust and maintainable), we have the additional problem that we just don't
try to maintain what we have.

From my perspective, I see a LOT of software on our distribution media that got
written a while ago, and for which there are no designated bodies (or plans)
for maintenance.  If it breaks, it's too bad, because we have too many other
important things to do to worry about that stuff.  In essence, we have lots
of code that's considered "done", even if it's buggy.

(Yes, until recently, one piece of software that I'm familiar with fell into
that category:  2-3 years of TOTAL neglect, even though it sees fairly high
use by our customer base.  It ended up having the dubious distinction of being
one of the top three buggiest pieces of software coming out of VMS, as measured
by bug report count.)

It sort of concerns me that we have the time and resource to create new buggy
buggy code, but we never seem to have the time or people to go back and fix
last year's bugs.  It really concerns me that few people see this as a problem.

    .7 hits a lot of nails on the head. I'd have to agree that the
    situation exists - and that we should fix the situation. So let's start
    proposing solutions, not just publicising problems.
    
    /a

Boy, this has been an educational experience.  I, too, am interested in the
polarization we seem to have in our company.  My message in .0 was mainly 
directed at the selling effort.  The feelings expressed in .7 accurately reflect
the attitude taken by many of our sales folks when in front of customers.  If
one doesn't believe that the product they are selling is absolutely the best,
then they are not going to be successful selling it!  Yes, we have our problems
with products and quality.  However, no one has anything better.  Period.  They
do a better job selling their products and managing their problems, mostly
behind closed doors.  How many times have we, when talking to a customer, blamed
someone else (read that air our dirty laundry) instead of just fixing the
problem as quickly as possible?  We must change the behavior.

Rah, Rah?  Damn straight!  I'm either going to get radically pumped about
working for Digital, or I'm going to leave.  As long as I see a significant
number of people who share my feelings, I'll be here.  When we all become
cynical and negative, I'm gone.  This stuff won't be fun anymore.

Am I a preacher?  Sure, why not, no one else has signed up for the job.  Imagine
what would happen if we all got radical and started working smarter, suggesting
good solutions to our problems, and then implemented those solutions!  We'd be
in gravy in short order!

So here's my challenge: find the problems, suggest a solution, preach the
solutions, escalate if necessary, and then implement.  And keep a positive 
mental attitude about the company.  Can we do that?  I guess we'll see.

Kelly

    I agree that .0 is not dealing from the top of the DEC.  Our products
    are mediocre, but we really fail in service.  Personally, I'm getting
    sick of hearing about us being #1 in "service", when all I ever hear
    from customers is a non-stop litany of horror stories.  Who should I
    believe?  I'll stick with the customers opinion, thank you, because
    customer perception IS reality....whether we like it or not.
    
    I think we are kidding ourselves.  Take the CSC's for example.  They
    put a lot of effort into customer surveys, and they are usually quite
    complementary.  But, they don't survey customers who have dropped CSC
    support....wonder why??

    re .14
    
    I agree - our collective consciousness has taken a real beating but we
    are the ones that need to work out how to succeed!
    
    Why is it that every time an interesting topic is brought up for
    discussion, within 10 notes we are down in the bowels of software code
    or hardware chips?  I think that is part of our problem.  We are
    always beating ourselves up and never looking at what we have done
    right.
    
    I choose to see the glass as half full.
          

Re: .13

Aaaaagh, I've got to defend this one....


>    Getting an engineer to fix a bug (or a batch or bugs) is like pulling
>    your own teeth.  Too many engineers would rather write code than fix it. 
>    Even getting an engineer to fix THEIR OWN CODE is difficult much less
>    fix someone elses.
    

This is a support type person speaking I presume...


If engineers could get the funding to fix the bugs, rewrite bad code, etc. (the 
list is endless)  engineers would to the job willingly.

The problem is getting the funding to this type of work when working on a "new" 
bit to a project.

We can't do the task without the Project Manager's permission, who has to get 
permission from the customer who is paying for the release.


The number of times engineers are frustrated by Project Managers and customers 
who refuse to see the wisdom of overhauling code that in their opinion "works" 
well enough (they have short memories and they are not the ones on the 
receiving end of the "bugs", their Users are) and customers rarely see the 
point in paying for something that will (in their view) give them no added 
functionality.    The fact that their support costs will be reduced 
significantly is "another budget"...especially relevant to internal 
"customers".

Once a release is "out the door" the Development team is no longer "allowed" to 
fix bugs.  They have to go to the Support Group to fix, even if a member of the 
Development Team found the bug in the first place !


It's a whole heap of nasty red tape, and someone has to dig deep in their 
pockets in the end, and that's the problem.

    Re: Note 1858.1 by HAAG::HAAG
    
>   I don't disagree with anything you have said. However, I believe, and
>   quite strongly, that:
>   
>          You Get What You Reward.
>   
>   A lot of people don't want to hear that. But it's true. I don't want to
>   ramble on about metrics again. But it IS true. And yes, we have mostly
>   ourselves to blame for much of our pain. 

    This reminds me of the way it was put in an excellent book I am
    reading, "The 7 Habits of Highly Effective People", by Stephen Covey:

    	Water the flowers that you want to grow.


    Some respondents here have pointed out that our problems are more to do
    with the way we do business than with our product offerings. Having
    been with DEC in sales for 8+ years, I must tell you that we make the
    selling process so incredibly complex that we almost paralyze
    ourselves. 

    To sort out every configuration detail and "gotcha", to include every
    unbundled part and option, to quote every little add-on service you can
    imagine from Recover-all to telephone support to extended warranty, to
    installation services, to include every little cable and adapter and
    prerequisite software license and media and documentation, to include
    license upgrades, and then hope like crazy you can get the allowance
    approved to beat the competition, the order entered properly, shipped
    on time, corrected after the inevitable screw ups, supported after the
    sale, to do all this....

    ...And then have enough energy to do it all over again, this is a
    miracle. We make it so complicated and frustrating, even for those of
    us that feel we have a good understanding of the products and
    customers, that it's a no wonder to me why we are not more productive.

The .0 note just maybe took some liberties with how/why we got
where we are, but that's not important.  The important point is,
the only way we will survive is follow his(?) prescription:

    VAX VMS systems can solve many many problems that customers
    have today, better than the competition, and with a growth
    path that nobody can touch.  You can dismiss these customer
    problems as "legacy applications" if you want to be 
    pejoritive, but they are real and we have the best solutions
    and, finally, maybe three years late, both good price/perf
    and solutions to annoying software licensing issues.

We will not survive to bring the new attitude (.3 I think) to the
UNIX market, and to customers who are committed to the idea of
UNIX, unless we first turn around the VAX VMS business.  

Bob

I'm sorry, but I do have to respond to .13:

I am an engineer, or at least WAS when I accepted my current job.

My job was outlined to me as fixing bugs in one of our most buggy pieces of
software (also one that gets used by lots of people).  I interviewed FOR a
job fixing bugs, and happily ACCEPTED a job with a very narrow list of 
responsibilities:  Fix bugs, then when I'm done with that, Fix more bugs.

I sort of rankle when someone tells me that you can't make engineers fix bugs.

So, why am I not fixing many?

Well, I've got a ton of process here that stops me at every turn.  Fixing a two
line trivial bug (something that has low risk, is obviously and reproducibly
wrong, and which is trivial to fix without affecting other code flows or 
functions) takes a week due to this process.  If the process guaranteed that
I was making zero defect (or six sigma) bug fixes, it might not be so bad.
The trouble is that most of the process is a reflection of the fact that 
management is terrified of anyone changing anything in the sources, even if
it's to fix existing bugs, and even if the person making the changes knows
what they're doing.

Thus, it is equally difficult (or easy) for me to make valid changes that reduce
bug counts as it is for me to check in totally bogus, broken, bug riddled code,
because the process does little to prevent the latter.

So, let's review my job:

1. I'm supposed to fix bugs.
2. It's not going to be easy, due to process.
3. It's not going to be respected by MANAGEMENT, since none of it contributes to
   producing new, revenue generating products.
4. It's not going to be respected by other engineers or management, since it's
   "wimpy" user mode code, and not something really "macho" like device drivers.
   (Fortunately, macho isn't one of my goals in life)

So, when I pick the buggiest corner of the product I'm responsible for, and write
a long range plan that says that I want to analyze the existing code (using
formal analysis and tools dedicated to such pursuits), and that I want to 
re-engineer the parts that are found to be the most buggy, poorly designed or
least maintainable, I get slightly irritated when my boss tells me that I have
more important things to do.

Sort of like "You're too busy cutting down trees to stop and sharpen your axe!"

Of course, I get tremendously irritated when people suggest that you can't
get engineers interested in fixing bugs.

Then again, this is partly why I'm no longer a software engineer.

Note 1858.22
XCUSME::MACINTYRE
    
    >re. VMS selling.  Ken and Z both went to lengths to say that we have a
    >clear migration path from VAX to ALPHA and to get out there and sell
    >VAX's.  Until they said so in the DVN, I had not heard a single sales
    >reps mention it.  I DID hear a lot about us announcing ALPHA way too
    >soon and that no one would buy from us until it was ready.  How could
    >knowledge of this migration path be so limited until the DVN?  It seems
    >to me that this information is basic to the sales force

During the DVN, which was on April 15, it was stated that the migration path
would be announced on April 17.  Has anyone heard such an announcement?  If
so, where was that announcement made?  I haven't seen it in VTX.

george

    I'm in SDT (part of TNSG).  I've been in DEC for ten years, and
    have fixed bugs for most of that decade.   When I was on VAX 
    Pascal,  we did nothing but fix bugs for a year (at a rate of
    about one a day per person, including a test system run and
    building a fixed Pascal kit to send out to the customer who had
    reported the problem).  Only when the pile of SPRs was gone did
    we go on to planning the next version.  (There's a long story about
    why there were so many bugs, but I wasn't part of the project then).
    
    I'm also familiar with re-writes:  a working Ada compiler was thrown
    away, for example, and the whole thing re-written from scratch; VAX
    DEBUG was largely re-written to improve its structure and reliability
    and to make it more portable.  In my group, as far as I can tell,
    bug-fixes have always had a high priority.
    
    While I can't claim that the internals of the products I've worked
    on are entirely beautiful, they are by no means spaghetti;  since
    I wasn't the author of most of the code in F77DEBUG, VAX Pascal and
    various BLISSes, I think my opinion is the one most other engineers
    would share.
    			-John Bishop

    Re .22:
    
    > Neither reply contested that point about bug fixing being a low
    > priority.
    
    Bug fixing is not a low priority.  I can't speak for VAX/VMS, but in
    the RSX and current Berkeley Ultrix group, fixing bugs is a higher
    priority than most things.  Getting new hardware support into a system
    takes precedence, but not much else does.  Even in Alpha/VMS, there was
    a lot of effort put into fixing bugs.  Obviously in that case, the code
    had to be ported before it could be debugged on the new platform, so
    debugging took a back seat to that, but it was still a priority.
    
    Fixing bugs can be made high priority or low priority, but there is one
    rule that should be followed that Digital is disobeying:  Fixing bugs
    CORRECTLY should be an even higher priority than fixing bugs.  And
    that's not the case in Digital.  Engineers aren't given the latitude to
    reorganize variables to make modules modular, to restructure code that
    has become spaghetti from changes, or to redesign when it is needed. 
    It is always more important to fix the proximate bug and move on.  The
    result is that modules get a patch that fixes one bug but makes the
    overall system more of a problem to maintain.
    
    I stated what the solution for this is; it's the same as the solution
    for many of Digital's problems:  Stop selling the long-term for
    short-term profits.  To get the release out the door, Digital foregoes
    keeping the software in a proper state.  To save salaries, Digital
    foregoes hiring new college graduates.  To cut expenses, Digital
    foregoes basic research.  It worked fine to keep profits up in the
    past, but it gave up Digital's long-term profits.  Now Digital has to
    pay the costs it avoided earlier -- with interest and penalties.
    
    Worse, the longer this goes on, the harder the decision becomes to
    reverse it.  The investment needed to turn the company around becomes
    greater and greater as the hole gets deeper.  So the company becomes in
    worse shape to make the investment needed to change things.  The
    projections of the next few quarters, or even years, will show more
    money made (or less lost) if the decision is made NOT to invest in
    fixing the problems.  The company will NEVER make the decision to turn
    things around unless it looks more than a few years down the line.
    
    To solve the problem, Digital must give up the short-term and invest in
    the long-term, and it must do it now.
    
    
    				-- edp

Re: .3 (Mr. S.)

	I can not agree with you more.

	What alarms me is that DEC is divided into two camps, represented
	by .0 and .3.  In one case you have people who believe that all is
	right with the DECworld and the problem is all in our collective
	attitude.  In the other case, you have people who believe that our
	products and strategies have been deficient.  So you have those who
	believe that if you believe real hard, things will work hard; and those
	who believe that if you work real hard and fix what's broke, things
	may get better.

	There's no hiding which camp I belong to.

	This company has been seriously out of touch with reality (i.e. the
	"real" marketplace) for some time.  I _think_ I see signs that 
	*finally* some people here are beginning to come around to begin and
	deal with that reality.  I honestly do not know if it will be enough
	to save DEC.  I admit I've been one of the folks living in the dream
	world at times.

	I hope everyone will reread .0 and .3 again.  The difference is
	most enlightening.  Yes, both authors work for the same company.

	Steve

Some more from the .0 corner!

I know that we are not perfect!!!  Boy do I know it.  Customers tell me almost
everyday.  I do know that we are a whole bunch better, from a product standpoint
than most.  This is true, gang.  The market would like for us to be all things
to all people.  We're probably the only company striving to do it, so of course
it's difficult.

We ain't perfect, but we're pretty damn good!

How about focusing on fixing what's wrong while focusing on the postives?  We
have got to stop being negative.  If we don't we fail.  Simple.  Can we do that?
What about this bug thing?  What if we, I mean we, tell Engineering that their
most important priority is bug fixes?  Let's do it.  Insist!  It just might
work.  Bitching in this notes conference doesn't do a damn thing, except piss
a bunch of people off.  Counterproductive gang!

Come on!  Let's get the spirit.  If you don't want the spirit, evaluate why 
you're here and make a tough decision.  We need everyone pulling on the oars
and in the same direction, for a change.

Peace

    
    
    	Kelly,
    
    	Re-read .5
    
    	I worked for an OEM before coming here. I have been a DEC
    	enthusiast since I got to work on my first VAX. I liked
    	the PDPs too. They are all workhorses of the first order. I turned
    	down jobs working on IBM and other machines in order to come
    	to work for one of the best computer manufacturers I knew-DEC.
    	I still think we make a good product but we do need to start
    	*listening* to comments like these from our customers. These
    	are the same comments I made to our DEC rep many years ago when
    	I was a customer working for the OEM. And those complaints 
    	even took into consideration the OEM discount. I used to	
    	*fight* like crazy to keep the engineers from purchasing
    	3rd party hardware based on cost comparison. BUY DEC was the
    	argument. Keep the system as pure DEC as you can I told them.
    	That's a hard one to keep pushing when dollars are as short
    	as they are right now.
    
    	Now that I have had a few years working in DEC software support and
    	talking to customers every day, I get the feeling that some
    	of our customers (generally system management types) are struggling
    	with the keepers of the $$ at their places as well. We need to
    	get coordinated internally and do so quickly. If I could wave
    	my support wand and make CAMELOT happen I would do so but I can't.
    	We ALL had better start pulling together and I don't mean the
    	royal WE. I mean all of us. Engineering, Manufacturing, Sales,
    	Support. If we could just get our collective egos checked at the
    	door and start working together to deliver WHAT THE CUSTOMERS WANT
    	at the price they can afford and then DO DELIVER, I know we would
    	see some of the 'good old days' return.
    
    	You indicated there is a lot of complaining in these notes files
    	and I don't disagree. However, what you are seeing is the
    	manifestation of repeated frustration in people who really do
    	want to do a good job, put out a quality product and go forward
    	but are unable to do so or to make their voices heard in any
    	productive vein. I have made suggestions and have sent them
    	"up" somewhere...I will continue to do so because it is in my
    	best interest to help us succeed. I hope and believe we will
    	if we all pull together.
    						kim
    					one_of_the_little_people
    

>What about this bug thing?  What if we, I mean we, tell Engineering that their
>most important priority is bug fixes?  Let's do it.  Insist!  It just might
>work.  Bitching in this notes conference doesn't do a damn thing, except piss
>a bunch of people off.  Counterproductive gang!
>

	Oh please !  Are you the only one in this company
	that does not have the trademark flat spot in the 
	front of your skull ?  You know, the one you get from
	beating your head against a brick wall ?

	Engineering responds to critical problem reports....
	period.  You tell "engineering" to get their act
	together, and "engineering" will tell you to p&$$ up
	a rope.... You don't sign their paycheck, they know it,
	and that's the end of it.

	Don't look now, but the closest common manager you and 
	they have is probably KO.

	The problems are fixable, but it'll take an iron hand,
	and the destruction of the "job for life" mentality.

	Steve H

  Re .29 (Steve) (+ previous)

> Engineering responds to critical problem reports.... period.  You tell
> "engineering" to get their act together, and "engineering" will tell you
> to p&$$ up a rope.... You don't sign their paycheck, they know it, and
> that's the end of it.

  As some of the preceding replies have shown, there *are* certain groups
  who *do* believe in fixing bugs.  There are also bureacratic obstacles
  in some cases, as well as a questionable mindset in others.  Unfortunately,
  you are exactly right as far as a number of supposedly "critical" or
  "strategic" product groups are concerned.

  The "mindset" problem is one that worries me a lot (eg., .18) and I'd
  appreciate it if someone could explain it to me :

    Why should the customer [or any other internal body for that matter] be
    expected to pay to get a bug [ = error = failure = lack of quality ] fixed
    in the product that they have already paid for (when they bought it) ?
    Why should they be concerned about the politics of fixing a problem that
    should not have arisen in the first place ?  Why should the customer be
    penalised for the incompetence of the originator and those supposedly
    responsible for testing the product ?

  I'll admit that there can be obscure timing issues - especially when adding
  support for a faster platform - but the majority of product problems that I
  come in contact with are simply sloppy work ... 

  Examples :

    Memory leaks caused by "forgetting" to free up the allocated structures
    (one line addition required, as documented in our own manuals as well
    as third party ones) ;
    Access violations due to not checking the return status from a function
    (again, as documented in all manuals) ;
    Random lines drawn when coordinates slide beyond a certain range (no
    checking performed within DEC code, simply passed across to hardware) ;
    Documented qualifiers to commands that simply didn't work (ie., the
    change was approved to add the functionality but it obviously wasn't
    tested as it could _not_ work in that implementation) ;

  The list goes on and on.  Maybe if you (.0) had to handle the customers
  *after* the kit has been sold you might understand why "Hey boys, we're
  the best" just doesn't cut it.  Maybe if you (generic) had to handle
  customers with long-term "highest priority" problems, or had to try to
  get one-line fixes built for the customer's version (rather than the next
  field test), or had to get an official response to a problem that was
  isolated months ago (but sat on by "Engineering"), or had to track down
  a bug to find that it was recognised as a problem area under v1.0 (but
  still shipping in "v3.1") ... maybe _then_ you would be able to say you
  have a better understanding, not only of the customer but of DEC itself.

  Yes, some groups are superb but other groups are abyssmal.  As Steve (and
  others) suggested, there is probably no-one below KO himself that can get
  the latter group to even start approaching the former.

  Frank

     The first step to getting better is admitting that you are ill. I think
  being honest about our shortcomings is the first step to doing something
  about it. The problem is that there doesn't seem to be a lot in the way of 
  the second step...doing something about it.

     I work in a Product Assurance group and could tell you stories.....
  TEAM is what is missing in my opinion. Somehow everything has gotten 
  compartmentalized. "That's there job! Mine? No that's his job", etc. etc.

     Frankly the worker bees WANT to do a good job but there seems to be a lack
   of LEADERSHIP. Leadership (to me) means being able to make sound decisions
   when choices need to be made instead of being bureaucratic.

     Processes *are* important and need to be developed. They are living in the
   sense that they need to change.

     Change and leadership......



      - Bob

Re .31

I think you've made a good point.  I've worked both sides now, at the CSC
supporting stuff, and now in engineering producing stuff other people are
going to have to support.

I'd like to think that most engineering people do not set out to produce a
poor product (it's certainly not one of my goals to wake up and say "I'm gonna
make some support persons life miserable today").

I'd also like to think that most support people do not set out to provide
poor support (I know I certainly didn't, nor did anyone else I knew at the CSC).

Being a TEAM is the right goal.  The group i'm with was at one point doing
a program by which people from the CSC's (and field too maybe) spent time
with engineering.  This was a step in the right direction, but maybe
not far enough.  I'd like to see more engineering people spend time as well
at the CSC's and in the field.  In order to be a team, you have to understand
(or at least have a feel) what it is that the other players do.

There is more then one ivory tower in this company, and to say that one group
has a monopoly in this area, seems to me to be ignoring the larger issue.

fwiw

--Scott

    RE: .28   It is often said that these are read.  I think Kim is right
    and it is the people just continuing to do their job that are keeping us
    in there.  Too bad they may not the same ones who get the recognition.

     Everybody's on the same side.  If you didn't care about the issue, you
wouldn't have posted a response to the note.

     The cynical/sarcastic/depressed responses - I find that cynicism always
springs from hope.  If you didn't have hope to start with, you'd have no
reason to be cynical.  People are usually cynical or negative because they
expect things to be better than they are.  But the accurate criticism that
comes out of this often gets tied up with lots of nasty, unhelpful emotions
(that SHOULD be expressed (does no one any good to pretend they're not there),
of course, but they should be separated from the facts).

     The rah-rah responses - this is a more obvious expression of hope, but
also a desperate one.  It amounts jingoism to just blindly express hope,
thinking that saying positive things will make them true and dumping on people
who are saying negative but honest things (another kind of common emotional
response that needs to be expressed, noted and separated from the facts).
But enthusiasm certainly signifies hope.

     The listen-to-the-customer/change-the-process responses - dead on.  We've
demonstrated that everybody wants things to be better.  They're all just
expressing themselves differently.  Parts if the company, here and there, are
probably already working better and smarter.  Hearing more about their
successes (and how they overcame difficulties) might be very beneficial for
all of us.

     The parts of the company that aren't working better and smarter need to
change.  It's scary to change, to let go of old, bad habits, to let go of
carefully rationalized cynicism or blind pumped-up positivism, scary for both
managers and grunts.  It frequently means listening to things you don't want
to hear, or thought you didn't want to hear.  Or letting go of things you
thought were important that really weren't.  It's also a lot more satisfying,
enjoyable and fulfilling.

     The one trick is that it has to be cooperative, not adversarial.  If you
change and your boss doesn't, or your boss doesn't and you do, it does neither
of you any good.   And it doesn't do the company or the customer any good,
either.
		not-the-same-Robert-M.-(Star::)Praetorius-that's-in-note-1562

Re: .22, .30 and no doubt others.

>  The "mindset" problem is one that worries me a lot (eg., .18) and I'd
>  appreciate it if someone could explain it to me :


Mine is not the "mindset", I and all the other engineers who works around me
would *LOVE* to be able to circumnavigate the "red-tape" where bug-fixing is 
concerned, it is one of the more frustrating aspects of our job.


>    Why should the customer [or any other internal body for that matter] be
>    expected to pay to get a bug [ = error = failure = lack of quality ] fixed
>    in the product that they have already paid for (when they bought it) ?


Basically the customer always pays in the end.   This is either paying for the
development/purchase of the product, or for the Software Maintenance Contract.


My end of the equation falls into the "Development" budget.  Bug-fixes falls
under the "Support" budget.   We "cannot" do bug-fixes in development mode,
this is why all bugs are passed to the Support group, and as an end result 
usually ends up costing the customer more....but it's a different budget isn't 
it !!!!!!!

I personally do not support this way of doing things, but until the process
changes I can do nothing (at the risk of losing my job) about it.   I talk to
people, I write memos etc...but *I CANNOT PERSONALLY AND INDIVIDUALLY CHANGE
THE PROCESS*. That has to come from the "top". 

So .30 (Frank) , please don't accuse me of having this "mindset", I was just
trying to explain why "Engineers won't fix bugs". 

    Kim,
    
    You're not one of the little people to me ...
    
    Chuck

  Re .35 (Jane?)

> Mine is not the "mindset", I and all the other engineers who works around me
> would *LOVE* to be able to circumnavigate the "red-tape" where bug-fixing is 
> concerned, it is one of the more frustrating aspects of our job.

  In that case I apologise.  From my viewpoint (a "support type person"), one
  of the more frustrating aspects of *my* job is to have to pretend to the
  customer that the right things are happening to get his bug fixed whilst
  knowing full well that the only obstacle is not technical but political.
  The alternative is to admit to the customer that it really *is* as chaotic
  & disorganised as it appears to him, that there is no earthly reason why it
  should take this long, and that this company is incapable of providing the
  support that it charges for on certain products.

>>    Why should the customer [or any other internal body for that matter] be
>>    expected to pay to get a bug [ = error = failure = lack of quality ] fixed
>>    in the product that they have already paid for (when they bought it) ?
>
> Basically the customer always pays in the end.   This is either paying for the
> development/purchase of the product, or for the Software Maintenance Contract.

  My objection wasn't to making money out of maintenance contracts but to the
  combination of relying on the latter to cover up the poor quality of the
  product then refusing to provide an acceptable level of support when the
  "bill" comes in ... as they are too busy adding new bells & whistles (that
  may or may not work).

> I personally do not support this way of doing things, but until the process
> changes I can do nothing (at the risk of losing my job) about it.   I talk to
> people, I write memos etc...but *I CANNOT PERSONALLY AND INDIVIDUALLY CHANGE
> THE PROCESS*. That has to come from the "top". 
>
> So .30 (Frank) , please don't accuse me of having this "mindset", I was just
> trying to explain why "Engineers won't fix bugs". 

  Again, sorry to have picked on you ... I realise that some people are more
  responsible than others - ditto for engineering groups - but misinterpreted
  your reply as supporting the process rather than simply explaining it.

  Frank

Re: .37


Phew...glad we've got that one cleared up !

:-)

    
    	metric's drive an awful lot of behavior. Project Leaders,
    managers, principal engineers are expected to be able to navigate
    the political waters - especially when it's time to compromise
    due to political situations.  These most often due to the fact
    the major players in any situation are being measured in different
    ways - ie: the output product has many meanings of success depending
    on what function you may be serving.
    
    	I would suggest that the more players, the more conflicts, and
    as a natural result, more compromises in a solution.
    
    	We have to realize we are competing head on with very small
    shops (especially in software) who can beat us in functionality,
    time-to-market, and product cost.  The success of both DOS and UNIX
    have really nothing to do with being "quality" platforms in the
    sense we usually use. They are successful because they allow the
    small player entry to compete with those of us who've really become
    so over-weight in so many areas, that we long ago lost site of our
    feet.
    
    	It is really easy to identify the problem - always the other
    peoples fault!  In fact, most people want to do the quality job.
    However, who wants to slit their own throats?  I know we have very
    high quality people in areas we can no longer afford.  Suppose you
    are one of them - would you fall on your sword?  This is the
    decision facing the management, and i contend that if we are all
    the dedicated, caring individuals we say we are, we would find this
    task VERY hard.
    
    	While it seems so many are into KO bashing these days, I'm real
    pleased to hear my CEO saying we'll cut only where we must, and
    we won't cut because some consultant says so.   I'm also real
    pleased that he identifies our problems not due to short falls
    in a given Buzzword Market, but due to the failure to not listen
    and respond to customer needs.  The ONLY thing that powers the
    success of MSDOS and U**X is the solutions made available due to
    enterprising folk who seized the day while we were too busy admiring
    ourselves.  Operating systems are platforms for solutions, not
    solutions in themselves.  We kind of forgot that part....
    
    	bob