Conference 7.286::digital

    For the curious, the memo can be found at asics""::strecker_memo.txt...
    for the moment.

    
    My thought: where is VMS? If it is still under Demmer, I feel its a
    mistake. VMS needs to be treated as software, not special-cased to be
    under a hardware VP still.
    
    All the software engineering methodologies and practices that exist in
    the rest of the software engineering groups need to be applied to VMS.
    
    Finally, I want to hear when software engineers will have real metrics
    applied to them in terms of bug rates affecting pay rises and
    promotions.
    
    /a

    ref .2
     
    >applied to them in terms of bug rates affecting pay rises and
    >promotions.
    
    Iam not sure I understand this. do you mean the raise is based on the number
    of bugs they find and fix? or they get less raise if they cause more
    bugs in the software?

    If it is the first, then it is easy to add bugs in your code, and then
    fix them , this way you can look good.

    if it is the second way, then it is easy not to cause bugs in the code,
    just write very little code !

    either way, would this not be hard to implement? , and Iam not sure it
    is the best way to evaluate software engineers.

    just my 1 cent worth,
    /nasser
    who_wants_to_be_a_rocket_scientist_one_day

    The best way to evaluate software engineers is on their work. If they
    do their work well, then that is fine and I have no argument with their
    getting pay rises and promotions. What I *do* get upset about is when
    people do a bad job and get rewarded anyhow.
    
    My definition of doing a bad job includes, but is not limited to, bug
    rates.
    
    /andy

��    getting pay rises and promotions. What I *do* get upset about is when
��    people do a bad job and get rewarded anyhow.

    So, where do you propose Digital gets Supervisors and
    Managers for engineering???

    they shouldn't come from the engineering ranks, it's hard enough for 
    engineers to manage themselves let alone anyone else.  Besides when a
    good engineer is promoted to management the company looses a good
    engineer and gains a bad manager.

    should come from people who have been educated and trained as managers
    and have the nature to do it well.
     

    Some engineers can make good supervisors and managers, but this
    shouldn't be the sole career path available for them.
    
    ENough of this rathole, what about other thoughts on STreckers memo?
    
    /a

    Keeping VMS and U*X under Demmer makes sense if you consider the OS
    as part of the basic platform. However, I am somewhat skeptical about
    hardware people managing S/W engineering. They're two very different
    disciplines. Though I have heard people wonder if there was any
    discipline in S/W engineering. :-)

    I do see a need to tie shipping cycles for operating systems with new
    hardware. This requires some close cooperation. Keeping OS with H/W
    seems to me to be a good idea. With one caveat. OS development usually
    trails H/W development. I'd hate to see buggy OS software shipped out
    the door because "the hardware is ready NOW." IMHO, something has to
    be done to improve the process around insuring quality in base system
    software. I'm not sure who the right person to do that is. Maybe that's
    what McCabe's focus will be?

    Christ I would expect to move back more involved in the storage space.
    We're starting to get into the commodity storage area and that's an
    area with a lot of growth potential. That's his background anyway as 
    I recall.

    			Alfred

    I thought the company was getting into a deeper understanding of
    modular operating system design and the demarcation of hardware
    dependent functions from hardware independent functions.
    
    Is the "party line" still tight coupling of the hardware and operating
    system?
    
    I've read some denials, in fact, that Alpha reflects a VMS-oriented
    philosophy of what hardware ought to implement.

>            <<< Note 2175.8 by CVG::THOMPSON "Radical Centralist" >>>

>    However, I am somewhat skeptical about
>    hardware people managing S/W engineering. They're two very different
>    disciplines. 

The two disciplines have never been all that different, and they
are getting more and more similar.
Hardware is getting more software-like with the introduction
of more CAD/CASE design tools, and software is getting more hardware-like
with its recognition of modularity, reusability, and product creation
process.

- tom]

    	VMS *has* been under Demmer for some time. The question was whether
    all operating systems should be under Demmer (along with hardware
    engineering) or under Stone. I also think it makes sense to couple the
    operating systems with the hardware. The groups work fairly closely
    together anyway. Those days of hardware engineering driving the ship
    dates "whether the software is ready or not" are long gone. You find a
    lot of engineers in hardware now with a good appreciation for software
    and vice versa. Both sides know the tradeoffs and when a product is
    ready to ship.
    	I've been involved with Alpha engineering since May of 1989. I can
    say without reservation that the hardware was not designed to
    accommodate VMS (and I'm in the VMS group). We tried hard to find a
    balance, hardware features which would simplify the VMS port and yet
    not compromise the complexity or performance of the chip. You did see
    a lot of VMSisms in the early versions of the SRM, but that's no longer
    the case. I think the OSF and NT folks would agree that a reasonable
    balance was achieved.
    	Demmer has a lot of experience managing software as well as
    hardware. He did so in MSD and continues to do so with VMS. The fact
    that upper management wants to give him all of OS software is
    indicative of the confidence they have in him.

    
    I wish Bob would think about bringing in/building a WHOLE NEW TEAM
    (with NEW NAMES). Everytime I read about a shuffle at the top without
    hearing any new names I feel like things are really NOT changeing.
    Kinda scary.
    

re: .0

> I'll believe that one when the policy preventing posting of
> mail messages is rescinded.

Oh, I don't think you'd really like that, Dave.

-Jack

    Re:  .12 - um...it's called the birdcage theory of management.  Take a
    cage full of birds and shake it.  They fly to different branches, but
    it's still the same old birds.
    
    Are we having fun yet?
    
    /M

    >Are we having fun yet?
    
    Not if we're all sitting at the bottom of the bird cage looking up ...
    
    Steve

    i dont think it is too nice to keep referring to our management as birds.

    /nasser

    re: 16
    
    Does this mean that those who go to get a turkey will end up with a VP?

            <<< Note 2175.8 by CVG::THOMPSON "Radical Centralist" >>>

>    I'd hate to see buggy OS software shipped out
>    the door because "the hardware is ready NOW." IMHO, something has to
>    be done to improve the process around insuring quality in base system
>    software. I'm not sure who the right person to do that is. Maybe that's
>    what McCabe's focus will be?

I used to be technical support (VMS and application software) for the
Corporate Distribution Datacenter. We were NEVER at the latest version of
VMS because a bug could hurt Digital's ability to ship product. We were measured
on keeping the systems up and it WAS NOT OUR JOB TO TEST VMS. I often wondered
if every other big internal datacenter felt the same way. I got my answer with
VMS v5.5 because it was obvious that it was never tested in a large production
cluster (no offense intended to the testing folks, it is VERY difficult to TEST
everything and most test system ARE workstations). If we required all of our 
internal systems to run the final version of field test software (well maybe not
payroll :^} ) and provided a decent internal DEC bug fixing channel, I don't 
think our customers would see 1/4 of the bugs they do now. 

I have had at least 5 different customers accuse DEC of using the customers and
the initial ssb release as final test. The amont of grief and loss of reputation
caused from shipping buggy software is huge, but I wouldn't be suprised if a
large percent of the testing folks got hit in the last round as they COULD be
considered OVERHEAD. We all know the engineer writing the code should not be
the person to test it...

If we expect VMS to win against other operating systems we cannot afford 
another release like v5.5. I have customers that are still afraid to go to 
VMS v5.5-1 even though they own a 6620 upgrade for their buried 6520... They
prefer poor performance to the risk of an operating system upgrade (they will
upgrade ONE of their clusters next weekend). 

Dan Buckley
CT EIS

    	This is off the subject, but we DO run the releases on our
    production clusters in VMS before we ship. We suffer through a lot of
    instability at first until people feel the software is ready to ship.
    We have some pretty large cluster configurations here in VMS too...But
    as you pointed out, it's impossible to test every possible
    configuration and usage. The hope is that field test plus our own
    internal usage of the software prior to shipment would provide adequate
    coverage. Sometimes, as you've seen, it's not enough. This is
    recognized in VMS, and people are putting a lot more thought and effort
    into quality issues these days.

>    Sometimes, as you've seen, it's not enough. This is
>    recognized in VMS, and people are putting a lot more thought and effort
>    into quality issues these days.

As usual, after I open my big mouth, new info comes to light. I just read a
memo that contained a note in the decus notesfile from this customer... After
a meeting with representitives from VMS engineering, they are very happy with
the directions that VMS engineering is taking in the quality space.
Nevermind.
Dan Buckley
CT eis

> I got my answer with
>VMS v5.5 because it was obvious that it was never tested in a large production
>cluster (no offense intended to the testing folks, it is VERY difficult to TEST

	From time to time a product is tested and it fails that test. Do not
	assume that just because a product has serious bugs in it that it
	hasn't been tested and that the bugs are not known. I've seen a 
	number of products, over the last 10-12 years, ship with serious
	known bugs.

			Alfred

re Note 2175.21 by CVG::THOMPSON:

>         Do not
> 	assume that just because a product has serious bugs in it that it
> 	hasn't been tested and that the bugs are not known. I've seen a 
> 	number of products, over the last 10-12 years, ship with serious
> 	known bugs.
  
        As Edsger Dijkstra is famous for saying:  "Testing only shows
        the presence of bugs, not their absence."

Just to get a little deeper into the base system test rathole -

I haven't worked on the development of VMS as Steve has, but having spent
several years in the RSTS/E group, I can assure you (as can Alfred) that
O/S's are _EXTENSIVELY_ tested prior to submission even to field test.
In RSTS, we actually ran the software on our development nodes as we
continued development. No one could be more critical of the software
and any problems than the engineers who needed to have it functional
in order to get their jobs done. The problem, as Steve and Alfred both
indicated, and as has been agreed upon, is that the development environment
isn't always necessarily the best test bed for production software. As
an example, in RSTS/E, the processors spent 99.99% of their time running
the MACRO Assembler, the Task Builder, the Librarian, EDT, MAIL, DECnet
utilities and BASIC+/BP2. This doesn't put anywhere near the same work
mix or load configuration on the system as a real shop would, and isn't
even guaranteed to provide as much code coverage.

There's a limit to the type of testing an engineering group can put
a system to - that's why we have Field Tests.

-Jack

    There's also an equation of revenue versus cost of fixing post-release.
    
    It can be a pure business decision. Viz:  I knew of someone that tried
    to stop a buggy O/S release that was told that the O/S would ship 'no
    matter what' because we (DEC) wouldn't interrupt the revenue stream. A
    patched up release went out about 2-3 months later. The expense in
    terms of support and shipping a new release was dwarfed by the revenue.
    
    Such decisions are made every day by every manufacturer of hardware and
    software.
    
    /a

	A plea to everyone in notes conferences - please, please
	try to refrain from genralisations!  I've known some engineers 
	become VERY good managers; some people trained to be managers to 
	be lousy managers;  some managers to be VERY good engineers.  And 
	if you hold to the view that a manager should be someone who has 
	been trained and educated to be one, there is no logical reason 
	why that person couldn't be an engineer to start with anyway.

	In my opinion (not a de facto generalisation), good managers 
	and engineers (and any other job type, secretaries, nurses, 
	doctors, accountants, lawyers...) are born and develop their 
	talents with training, education and practice, they are not "made".

	Cathy

    re: .24
    Yes, indeed.  I can recall one instance, quite a few years ago, when
    I sat in a meeting and the marketeer thundered, "We're going to
    ship *ON TIME* even if we have to send out blank disks!!!"  Well,
    we shipped "on time" and paid for it for the next year, at least.
    I hope we've learned since then, but sometimes I wonder.
    

    .25 Generalisations can be very useful. I think you missed a point that
    was there to be seen - which was that it shouldn't be acceptable that an
    engineer must give up a technical career and become  a manager in order
    to advance in their career.
    
    In *general*, this kind of sideways jump can be counterproductive. Just
    because I'm a technical heavy and a very senior engineer doesn't mean
    I'd make a good manager. (No surprise to anyone who knows me..:-)) So
    there should be a career path other than engineer -> manager. In
    *general* the engineers career stalls unless they migrate into
    management. In *general* this is not a good idea - because DIGITAL
    doesn't usually invest a lot of time in training Engineers in
    managements skills - and VMS crash dump analysis skills are useless in
    most management positions.
    
    /andy

    Much as I hate to bring this discussion back to it's base...... (-:
    
    My sincere hope is that this new organisation and appointments will
    have some permanence (including the appointments still to come.)
    
    This will then give us the opportunity to do two things:
    
    1) Manage down through the rest of the organisation, the changes in
    product strategy and the engineering implementation.
    
    2) Measure our performance of this implementation at all levels. e.g.
    Not just a VP level, and not just at engineer level, but all the levels
    in between.
    
    Whilst doing this we need to ensure the we reward good engineers and
    good managers, and that we don't reward poor performers or bad
    behaviours. Our managers must also ensure that poor performance or bad
    behaviour does not get rewarded by being ignored or not challenged.
    
    Self-interest declaration: I am an Engineering Manager. My requirements
    are to be given clear goals, and to be measured on them. And not to
    be measured on the latest fire-drill that somebody thinks up in
    response to the latest pressure on them. (I can give several examples
    of how this type of behaviour has diverted the efforts of me and me 
    team from engineering, and required additional admin to defend our
    efforts.)
    
    My bottom line requirements for the new organisation is a period of
    stability where strategies can be determined, implementation in place,
    and allow management to be done and measurements to be made.
    
    If we continue reorganising the top at 2-month intervals, we can never
    *manage* our progress.
    
    JohnK