Conference 7.286::digital

   Re:      <<< Note 1852.0 by SDSVAX::SWEENEY "Patrick Sweeney in New York" >>>

I run to the same kind of thinking.

Whenever anyone feels the need to create a new department, s/he
should consider a spinoff with a startup contract and the
expectation that competitive bidding will determine whether the
spinoff lasts for more than one fiscal year.

I simply can't see most current managers as capable of managing
an organization of more than about 500 souls at a site.  Why
should we make management jobs undoable?

Dick

    I'd like to see us split into several entities:
    
		o DECSoft - producing applications software for all
    		  platforms, competing with Microsoft et al.
    
    		o Digital EQUIPMENT Corp - producing hardware to compete
    		   with IBM, DELL, Apple et al.
    
    		o DECServ - Customer services attending to pre and post
    		  sales needs of our customers.
    
    		o KObucks - the holding company initially funding the above 
    		  and taking a percentage of any profits they make.
    
    
    Each of the DECorganisations to own their marketing and sales
    operations, standing or falling by the profits made.
    
    My prediction would be that it'd be a damn hard world out there, but
    that this may be the only way that we can ever compete into the 21st
    century.
    
    /andy
    		

    I agree 100% with Andy, the split between hardware systems and
    software makes a lot of sense.
    
    Regarding the problem with 3rd, 4th, and 5th level managers in Digital
    now, they spend far too much time negotiating charter, metrics, etc.
    with their peers through the network of dotted lines.  They create and
    curse the chaos in one breath.
    
    They spend too little time:
    
    (a) preparing the business plans and budgets for their managers
    
    (b) faciltating the results that will come from the people they manage.
    
    Getting back to the basics of managing for results would be so old that
    it would be a new concept.

    Okay but with one big caveat.
    
    There should be NO turf wars.  If the "hardware" group decides to
    invest money building a piece of software, on the grounds that it
    improves the sales of their hardware, then that's fine.  For instance,
    a workstation group might want systems software to enable their WS to
    run software written for other hardware (emulators).  They shouldn't
    have to convince a software group to fund it; the bennie goes to the
    hardware.  That's the way PALcode is expected to work and it's an
    established (but not universal) tradition for "systems" software.
    
    And if the disk group wants to build software to enhance their ability
    to serve data bases, fine.  And if the mainframe group wants to port
    some application to their mainframe, fine.  Their bucks, no turf wars.
    
    Likewise, the software group should get no gruff if they write software
    for Macs, Suns, etc.  And if they decide that their multimedia software
    package needs a video or image peripheral, they can build that.  If
    they decide their AI program needs a coprocessor, fine.  Their bucks,
    no turf wars.
    
    The "charter" thing is a major disease.  Let market forces rule. 
    Obviously, if the "holding company" doesn't think a given unit is
    investing profitably, they can exert some supervision.  But it should
    be based on profit, not turf.

    add one more:
    
    	Digital... Systems Integration, Inc. - an 'independent'
    		systems integration company with the necessary
    		financial systems to do ANY kind of business such
    		as cost-plus (and all the variants thereof) for
    		govenment and industry.
    
    -Barry-
    

    
    Absolutely to .6
    
    I have this strange view that keeps coming into focus & out again.
    Seems to me that if Digital's major asset is our people, that should
    be because of their ability to get the customer what he wants. 
    
    Problem is that customer expectations keep moving in the real world --
    often faster than our loyalties to our products. I see frequent
    evidence of us bidding configurations that are not optimised on meeting
    customer needs, but are optimised on the highest ratio of Digital kit
    in the configuration.
    
    Not a recipe for success. Great potential revenue, but we lose the
    sale. Surely better to bid (say) 80% Digital, & 20% whatever, providing 
    the bid wins. More revenue that way -- & should be more profit.
    
    Pal of mine runs a software outlet in the UK. Gets 50% discount on all
    he buys, regardless of volume. Specialist niche market, high ticket.
    He needs to understand his customers needs, & choose the best CURRENT
    solution for their problem -- not yesterday's solution, but tomorrows.
    It's a 4-man band, & not equivalent to Digital -- or is it?
    
    Could we use our knowledge to become a re-seller, not a builder (other
    than for absolute core products)? Have we the capability to be an
    impartial knowledge store, able to give accurate advice to
    customers on best solutions from whatever source? Would customers pay
    enough for this service to offset loss of our own product revenues? 
    
    Could we use all our experience, test kit, procedures etc to be the
    industry leader in competent advice? Could we learn other people's 
    product sets (h/w, s/w, applications)? Could we learn to dump 
    yesterday's best when something better comes along?
    
    Would such an approach give us greater flexibility & closer involvement
    with our customers? Would it reduce our overheads? How many people
    could we afford to keep? Would we gain real profits?
    
    Perhaps this is no more than the functions performed by the group in
    .6. I know we cannot know everything. I know we don't have any monopoly
    on skills -- but we have an opportunity. 
    
    Any comment?  Is this naive, uncomfortable, stupid, or what? 
    
                          

    I view Systems Integration as a function of post sales, so that'd be
    part of DECServ. To seperate remedial and consulting services is a
    major mistake, because one can support the other.
    
    ...and yes, the organiations should stand or fall on the basis of
    PROFIT.
    
    As to the idea that if the hardware folks want to write software they
    should, my response is NO NO A MILLION TIMES NO. (With the caveat that
    their writing the device drivers to run the new bit of hardware makes
    some sense, but THAT'S IT). I am *really* fed up with hearing how
    software is easy/difficult/stupid/intelligent from all the hardware
    types in our company hierarchy.
    
    Let teh hardware people do what they are best at. Let the software
    people do what they are best at. Let the services people do what they
    are best at. 
    
    The reason we're where we are is because of attempts at
    cross-discipline work.
    
    /and
    
    

    Andy,
    
    I share some of your frustrations.  I am tired of hearing that software
    is the same as hardware, etc.  But, there have been some real disasters
    when we have gotten into complex systems like LAVCs and multi-host
    clusters and the field has been left with the pain because there has
    not been any one responsible for the  system to ensure system level
    documentation, testing, etc.  There needs to be some level of system
    responsibility.

    
    Re: .4
    
    I agree with this, but I think Andy Leslie is right.  If the
    hardware groups want some particular software on their machine
    then let them contract with a software group to write it for them
    just like any customer would.
    
    Steve
    

   Re:                      <<< Note 1852.9 by SQM::MACDONALD >>>

from my point of view, the major benefit to be obtained is that
none of the groups (nor the holding company) would have any say
about the internal activities of the others.  They are given a
head start in one niche, if they try to leave it, they will
either succeed or fail.  If they succeed, then there will be
more profits for the holding company.  If they fail, other
players in that marketplace will be available to take their
place.  What's the problem?

fwiw,

Dick

How about one step further...If the hardware company needs some software
written, it puts out an RFP. If the DECsoft co. can meet the requirements
cost effectively they win the bid! When we continue to "buy" from each other,
they're no competitive pressures to improve efficiency and product quality.

...Just a thought

    
    Re: .10
    
    Dick, I don't understand your point.
    
    Re: .11
    
    Definitely.  That is precisely what I meant in .9  Software would
    have NO say over whether the software the hardware group wanted would
    be developed or not.  They would only have the option of bidding for
    the business if they wanted it and, as you point out, if the hardware
    group wanted to go "outside" to have the work done, that would be 
    their decision, period.
    
    Steve
    

    Starting from the re-org I outlined in .0, we're getting some
    more ideas.  I want to emphasize that I'm in no position to officially
    advocate it.

    There's a real danger to say "Hey, isn't this what NMS is supposed to
    be?"  And the answer to that is in Andy's comments and .10.  We
    maintain dotted lines, complex interdependencies, etc. by business
    process decisions implemented 20 years ago by people who aren't here
    anymore and the people who run them now don't have the ability or
    interest to change them.

    I believe I've been poisoned by working with small, competitive
    software and systems integration companies are understanding their
    "management system": no decision takes more than 24 hours even if the
    CEO is involved, everyone understands what business they are in and
    what's profitable, and what's not.

    Digital's NMS is a band-aid on six inch wound.  It's the coordination
    of different groups, the constant interference and decisions from
    corporate, and the "UNIX strategy de jour" that's brought us here.

    	You know, I kind of like where this skein is going.  I'm having a
    	problem with one thing, however.
    
    	I'm really getting tired of people throwing the terms "enterpreneur" 
    	and "enterpreneurial" around in notes that talk about moving around
    	in a large, fairly soft corporate structure.  If you want to break
    	DEC up into autonomous divisions, I think it's a good idea, but it sure 
    	as hell ain't enterpreneurship.
    
    	You want to be an enterpreneur?  Here's what you do.  Mortgage your
    	house, sell your car, borrow money from your family and friends, tap 
    	your kid's college tuition and braces funds, and bet it all on the 
    	success or failure of your business.  If you lose, go on foodstamps. 
    	Having direct control of your destiny you will find, has a wondrous 
    	effect on clarifying your goals and concentrating your thought 
    	processes.  Now if you want to play store by moving around in a 
    	corporate feeding chain where the probability of ever missing an 
    	annual raise, much less a paycheck, is quite low, that's fine, but it's 
    	not *quite* the same.
    
    Larry

Andy is wrong in .7 - engineering is engineering, and hardware and software
have more in common at the design level than many people are willing to hear.
Yes, the implementation techniques differ, and the realizations present
those differences.

   ###  The most divisive force we have is when a discipline thinks  ###
   ###  itself special, and uniquely capable of solving a problem.   ###

You don't hire a butcher as a nutritionist if you suspect his skill set 
in nutrition is limited by his interest in meat.
You don't hire a hardware OR a software specialist for a systems solution
if you suspect their implementation skills bias their design approaches.

Steve is closer to the mark in .9, but misses the point that any customer
has the option to build as well as buy.

Dick is quite closer in .10

Divisionalization is an interesting idea, but the hard part of any breakdown 
is finding orthogonal businesses that won't compete (wasted resources from
duplication of effort) and can withstand arm's-length (market style) 
cooperation (extra cost from continual renegotiation with possbile new
partners).

- tom powers]

    Amen to .15.
    
    Hardly any hardware these days isn't software-driven, and I don't mean
    at the end-user buy-'em applications level.  Xerox has said that
    something like 80% of the cost of a new copier development is software.
    
    I've witnessed what happens when the two get too far apart.  We have a
    product (no names, of course!) whose hardware was cobbled together a
    few years ago in one country, based upon a different product's design,
    and which was intentionally crippled in order to not compete with
    another obsolete turkey that group was selling.  The software group has
    about 20 top-notch programmers in two other countries sweating hard for
    a year and a half to do a new release of the embedded code.  Their life
    would have been a lot easier if the hardware were slightly different
    (not hobbled).  But they have no say whatsoever over hardware.
    
    This separation leads to late, uncompetitive products.
    
    There's no magic bullet org chart.  Everybody needs to do what they're
    good at.  The old "systems" approach has failed, and we do need to sell
    software to everyone and hardware however people want it.  But hobbles
    are hobbles.

With an organization like that, some products would get lost in the shuffle.
Terminals and printers are combined hardware and software products; as are
communication servers, network bridges, etc. No one will succeed with these
unless both hardware and software work together. Separating the two functions
could result in one group dictating the design to the other, when the product 
would be much better if the groups designed it together.

Also, this would separate the organizations that design products from those that
sell them (to the outside world) even further. We have enough trouble when both
marketing and engineering are in the same organization. I think we'd find the
system integration people buying third-party products, and not going to the
engineering groups saying "We have a customer who wants xxx. What can you
develop that does this?"  Or "The customers like this feature but not that one."
They are likely to make their sales by buying products already available, and 
not giving the engineering organizations the feedback necessary to design
products the customers want. They would have to develop their own marketing 
organizations, duplicating effort. (Now, if engineering would listen to
marketing... But I don't want to get into that here.)


BTW - I am an engineer. I'd like to see the products I work on in use by
a lot of people. I have seen features customers wanted incorporated in a product,
and I've seen requests ignored. I've also seen cases where one customer
required a feature, and another customer required the feature not be present.
(We worked out a way of satifsying both.)

Anyway, to get back to the topic, there needs to be an overlying framework to
make it desirable for each of the split off companies to buy from the others,
but in a way that makes them all more competitive. I'd also combine hardware
and software, or split software into 3 groups: applications, operating systems,
and hardware-dependent (firmware, diagnostics, drivers, etc.) The latter would
best be part of the relevant hardware groups.

    
    RE: Systems level issues: Jack, you know that I agree that we're crap
    at handling systems level problems. My proposal doesn't directly
    address that issue, but I'd see low-level clusters stuff as hardware
    (including the class driver etc) and high level stuff as software.
    There'd be as much co-ordination then as now, after all.
    
    RE: Hardware and software being more alike than most people admit.
    Well, it's a nice hypothesis, but doesn't live with the facts. Hardware
    is essentially reliable and well designed in a multitude of ways.
    It is also largely a variation upon a few themes. SOftware isn't. There
    are more software packages on the market than 10 times the hardware
    bits. t's also produced by a far less reliable or predictable process.
    Sad but true. They don't need to be in one and the same company.
    
    It is important to look at those we sell against with and try to
    understand whether we in fact COMPETE with them. Canon and Epson are
    hardware companys and make some of the best printers around. They don't
    do software. They don't need to. Neither do our printer folk have to.
    
    The structure of DEC today is antiquated and based around the idea that
    hardware sells everything else. In my view functionality sells
    everything else. Usually this resides in software - the application is
    the system.....:-)
    
    /andy
    

    I like Andy's idea.  To define the functions of one company, use the
    OSI (or something like it) stack.  Layers 0-n are hardware, n+1 through
    7 (or the top) are software, everything above is consulting, support,
    etc.
    
    How do you cover such things as protocols or strategic solutions?  I
    assume that some protocols such as LAT or DECnet need to exist or be
    optimized in both software and hardware.  The same is true for
    proprietary items such as the imaging extensions to X.  If you have
    separate companies that find it easiest to incorporate "vanilla"
    standards into their products, how does this help or hinder our ability
    to leverage complete solutions (e.g., NAS, etc.)?
    
    --- Gavin

    re:.18
    Canon and Epson don't do software?  Shirley Huge Geste!
    
    What do you think their printers (and watches) run on?  Thousands of
    gates in ASICs converting printer codes into ink dots?  C'mon, they're
    processor-driven systems one and all.
    
    Now if you want to classify _embedded_ software with hardware, you're
    closer to the mark.  The product I alluded to a few notes back has
    hardware and embedded (downline-loaded) software.  And the software's
    basically portable to other hardware, but the software group lacks the
    authority today to specify better hardware.  (They tried.)  And the
    hardware group is pushing a different new product and the software has
    to support the lousy, difficult-to-program old hardware forever.
    
    Even Microsoft operates as two companies.  One produces operating
    systems (MS-DOS, Windows) and the other produces applications (Word,
    Excel).  They probably make more money selling applications on Macs
    than they do on operating systems or applications running on their own
    operating systems.  But they don't hobble the applications group in
    order to hurt OS-competitor Apple.

    Welcome to the 1990's.
    
    "No one will succeed with these unless both hardware and software work
    together."
    
    Who says that the form of this togetherness much share buildings,
    business practices, telephone network, and corporate owner?
    
    The "dictating" you fear is part of the reality of influence in the
    marketplace.  Can you imagine Digital thinking of itself as co-equal
    with Microsoft in discussing distribution?
    
    People who fear working at arms-length with subsidiaries or third
    parties with legally enforcable contracts and real cash flows at stake
    ought to get the experience.
               

    
    re: .18
    
    	I think too many folks trivialize the hardware design process.
    Using your nodename again as an example the limitations and variations of 
    hardware designs such as ASICs are only limited by the software used to 
    program these devices as well as the imagination of the programmers.
    How does one even define hardware versus software today? I don't think
    it's as easy as we think.
    	We usually hear something about 6 million lines of code in VMS. How 
    about the several million precision crafted transistors buried in
    semiconductor physics in each system? Combine that with the "embedded
    software" and customization and you will probably realize as much
    complexity and variety as with pure software design.
    	In terms of servicing a system, a similar discussion has gone on
    for some time in how to combine or break up Services based on hardware,
    software, applications, etc. I am of the mindset that we still need
    good generalists to begin the diagnosis of systems/solutions, then to 
    pass on to hardware or software specialists. Maybe the same can be true for
    development?
    	I agree with a few other noters, SI is the key; to me this implies
    keeping the units together, mixing hardware and software folks up more
    into teams and better understanding customer needs. It seems sometime
    that we are working too much on vanilla designs leaving us with a very
    confused customer trying to sort this and merge that.
    	 

I think anyone interested in this topic would enjoy the interview with GE CEO 
John Welch in the (I believe) July/August 1989 Harvard Business Review.  In 
the interview, he talks about how GE broke up into 14 businesses (NBC, 
aircraft, rail, etc.), each with the same simple approach to business.  He 
talks about speed, simplicity, and self-confidence.  How managers that are
insecure surround themselves with complexity, etc.

>               <<< Note 1852.18 by ASICS::LESLIE "Andy Leslie" >>>
>    
>    RE: Hardware and software being more alike than most people admit.
>    Well, it's a nice hypothesis, but doesn't live with the facts. Hardware
>    is essentially reliable and well designed in a multitude of ways.
>    It is also largely a variation upon a few themes. SOftware isn't. There
>    are more software packages on the market than 10 times the hardware
>    bits. t's also produced by a far less reliable or predictable process.
>    Sad but true. They don't need to be in one and the same company.

I think you are well off the mark here in your comparison.
Even if you are not, then what you describe is unnecessarily true,
especially the part about the software design process being unreliable
or unpredictable.  Why isn't it reliable or predictable?  People have proven
that it can be.  If you think hardware design is, why can't/aren't you
emulating the hardware process?

>    It is important to look at those we sell against with and try to
>    understand whether we in fact COMPETE with them. Canon and Epson are
>    hardware companys and make some of the best printers around. They don't
>    do software. They don't need to. Neither do our printer folk have to.

You've stepped onto my court.  I work in DEC's printer engineering group.
Canon has decided in the last few years to get (back?) into the complete
printer business (not just OEMing printing mechanisms) by doing software.  
Even if it's not the mildly visible page description interpreter software, 
it's always included the really embedded microcode and firmware that 
drives the guts of the machine (analogous the use of microprocessors 
in microwave ovens and automobile engines).

Of the 40 or 50 people here who work strictly in "printer engineering,"
about half do software and firmware and half do hardware.
The mix is somewhat complicated because many of us coordinate purchased
hardware and software components and engineer integration of the results.

I defend the similarities of effective hardware and software design
as someone who has contributed to both, including recommending
design approaches whose implementations as software, firmware, or hardware
were not decided until after the fact.

All for one and one for all....

- tom powers]

>    Using your nodename again as an example the limitations and variations of 
>    hardware designs such as ASICs ...
    
    Oh.  And I thought Andy's node was named after a brand of running
    shoes.
    
    <end digression>

re: .24

> Why isn't it reliable or predictable?  People have proven
> that it can be.  

Could you please give specific examples?  My understanding is that this is
only true in very specific problem spaces, or for significant increases
in development costs.  I'd love to learn about success stories that have
direct relevance to our development process.

re: Canon, and the gist of this discussion

It's a mistake to assume that specific application contexts are the same
as more general purpose software products.  Or, to put it another way, not all
software development is the software business; Canon is clearly doing software
development for the products, but they're not selling software. 
They're selling complete systems.

Some software can and should be done in cooperation with hardware
groups to build complete systems.  Much of the software we sell should
be totally independent of the hardware, to maximize sales opportunities.

   Gary

How would Alpha have evolved under the organization outlined above? Would VMS
be running on it or just OSF?

Lee

    Have you noticed how the discussion in this topic has begun to revolve
    around product design. That ISN'T the hard part anymore. Three people
    in a garage can build a product and OUTSELL Digital with it. If those
    three people didn't LISTEN to their prospective customers, design their
    product accordingly to solve those customers problems and distribute it
    in an EASY-TO-BUY manner, they would be broke in very short order.
    
    The questions of the day are how to build very short feedback loops
    into all the Digital processes so that the architectural and
    technological fantasies by which we delude ourselves can be destroyed
    quickly.
    
    <BEGIN HERESY>
    
    In the commercial market with which I have some contact I don't hear
    any prospective customers beating down our doors to get their hands on
    ALPHA. It will be nice if it improves the cost/performance
    characteristics of Digital computers. The strongest message I hear form
    the real world is "We can't afford the number of people it takes to
    keep your computers and applications running"
    
    <END HERESY>

Note 1852.24                 
>I think you are well off the mark here in your comparison.
>Even if you are not, then what you describe is unnecessarily true,
>especially the part about the software design process being unreliable
>or unpredictable.  Why isn't it reliable or predictable?  People have proven
>that it can be.  If you think hardware design is, why can't/aren't you
>emulating the hardware process?

    Software isn't as well-designed in DEC as hardware because the methods
    used are rather different. CASE tools would help, but common sense
    helps. I went to the Six Sigma for software course last year and heard
    all the good stuff that I did through sheer common sense 17 years ago.
    
    Hardware works. It's reliability is high. 
    
    Software IS different. 
    
    The reasons for why are a whole different topic.
    
    As for the software stuff, let me refine what I said earlier - DECsoft
    should produce *application* software. ok?
    
Note 1852.25                 
>>    Using your nodename again as an example the limitations and variations of 
>>    hardware designs such as ASICs ...
>    
>    Oh.  And I thought Andy's node was named after a brand of running
>    shoes.
>    
>    <end digression>
    
    Simon is correct. As he knows of course, since he's seen the ASICS GEL
    label on it :-)
    
Note 1852.26
>Some software can and should be done in cooperation with hardware
>groups to build complete systems.  Much of the software we sell should
>be totally independent of the hardware, to maximize sales opportunities.

    Absolutely.
    
Note 1852.27                 
>How would Alpha have evolved under the organization outlined above? Would VMS
>be running on it or just OSF?
    
    Anything you like could be running on ALPHA. First develop the
    hardware. Then start selling the hardware to the software people. Any.
    Including but not necessarily limited to DECsoft.
    
    

>        <<< Note 1852.28 by A1VAX::GUNN "I couldn't possibly comment" >>>
>    <BEGIN HERESY>
>    
>    In the commercial market with which I have some contact I don't hear
>    any prospective customers beating down our doors to get their hands on
>    ALPHA. It will be nice if it improves the cost/performance
>    characteristics of Digital computers. The strongest message I hear form
>    the real world is "We can't afford the number of people it takes to
>    keep your computers and applications running"
>    
>    <END HERESY>

    My views on this are twofold:
    
    
    		1) Our management toools need to work, work on all
    		   platforms, from all platforms and with an easy to use
    		   UI.
    
    		2) My bet is that customers buy functionality. They buy
    		   applications, which means they need hardware. The faster
    		   the hardware the better, usually, but first they buy
    		   the functionality they need.
    
    /a

I hope I'm not starting a rathole, but...

Some characteristics that tend to make software less reliable than hardware:
----------------------------------------------------------------------------

    - The "users" of a piece of computer hardware are generally software
      engineers - technical professionals in a closely related field who
      can specify what they want up-front.

      The "users" of a piece of computer software are often business and
      government and school and home users without much expertise in the
      fields of computer science or information technology.  Getting the
      specifications right is harder.  The software engineers may not be
      experts in the user's problem space, and the users rarely can give
      the engineers complete requirements.  As the doggerel goes,

	      "And then the user said,
	       With a snarl and a taunt,
	       It's exactly what I ordered,
	       But not what I want!"

    - Software is viewed as being "easier to change" than hardware - and
      so there are more requests to upgrade, change, or extend it, which
      translates into more opportunities for bugs.  We don't get lots of
      requests to change the VAX architecture around - or if we do, they
      don't get implemented without a LOT of justification which is hard
      to provide.  People want new software features all the time.

    - Fred Brooks points out that some types of hardware have replicated
      components - memory chips, for instance.  The replication is a way
      of reusing design.  In software, the way engineers reuse design is
      to eliminate replicated code by creating shared modules.  Thus, if
      you measure reliability in terms of defects per lines of code, and
      in terms of defects per given number of transistors, software will
      look worse than hardware, because it consists of unique parts.  (I
      wonder - if you counted each procedure call as the number of lines
      of code in the called routine, for purposes of defect measurement,
      would this level the playing field?)

On the other hand, there is a lot of similarity between designing new hardware
components and designing new software components.  The items above reflect the
differences in our *user base* and in our *reuse technology*.  But while these
are constraints on the designer, the problem-solving skills designers need are
not specific to either hardware or software - or computers, for that matter!

re: .30
    
>    		1) Our management toools need to work, work on all
>    		   platforms, from all platforms and with an easy to use
>    		   UI.

In a sense, a management tool often is an afterthought to make something
not well designed appear to work better.  If you think of it from a Quality
standpoint many tools may be attacking the basic need too late in the cycle,
i.e., they're "managing the unmanageable".  So LAVCs have been a management
nightmare for system administrators, but tools only mitigate that somewhat,
they don't address the underlying design problems.  Similarly all the work
that has gone into the queue subsystem, managing printers and print queues,
etc.  And VMSINSTAL as a software installation "tool" could never overcome
the poor initial design of the VMS system pack (poor in terms of separability
of code, static data and dynamic data).

So good tools are an aid to management, but there's only so much they can do.
    
								paul

    Time for my two cents, as a previous VAX architect and vitally
    interested and involved with the compatibility of the various VAX
    implementations.  I've also worked on lots of software over the years,
    so at least I straddle the HW and SW disciplines.

    SW is infrequently started over. Rather it is built upon and added to
    over the years.  HW tends to be rebuilt from scratch, repeatedly
    implementing the same functionality but at a higher speed or lower
    cost.  Examples: count the number of OSs Digital has constructed over
    the last 15 years and compare it with the number of VAX implementations.

    One of the major consequences is that the testing for the VAX
    architecture got better and better over the years, so that VERY few
    bugs were discovered by customers in VAX instructions in the last five
    years.  A handful at most.  Compare that to the thousands of
    outstanding VMS problem reports.  There simply is no comparable testing
    for VMS.

    SW releases add functionality, which is hard to test.  HW releases add
    speed and reduce cost, which add far less to the testing problem.

    I also strongly suspect that if one compares the number of conditionals
    in any significant piece of software, the count will be found much
    greater than any comparable count in a VAX processor, say.  Microcode
    (which is a very specialized software application with generally
    well-controlled inputs) does obscure many of the differences, but I
    suspect that even counting microcode conditionals as part of the HW
    will yield the same result.
    
    Try weighing the code listings for VMS and the prints (including
    microcode listings) for any VAX implementation.	:-)

    My firm belief is that SW is far more complex, worse defined, with
    fewer adequate testing suites, and more argument over "the right
    answer" than for HW.  Top that off with less expertise on the part of
    SW users, and SW has a far more difficult problem indeed.
    
    There is another side. HW tends to break of its own accord: junctions
    diffuse, fans crap out, and the like.  SW doesn't break; it may have
    been designed wrong, but once it is right, it stays right.  That is the
    one thing I know of that tends to be in SW's favor as far as
    customer-perceived errors.

    THe point is that same-company-coupling of harware thru to application
    software is a dead concept and has been dead for some time.
    
    MS DOS, UNIX, NT, and even VMS are not perfect but "good enough".
    
    And "good enough" means that they can carry forward all the software
    that was written before.
    
    So a hardware company wants to get UNIX or MS DOS running on their
    platform first.  Or System 7 if you are Apple, or VMS if you are
    Digital.
    
    So an application company want to get their application running on UNIX
    or MS DOS first, then some others.

.28>   <BEGIN HERESY>
.28>
.28>   In the commercial market with which I have some contact I don't hear
.28>   any prospective customers beating down our doors to get their hands on
.28>   ALPHA. It will be nice if it improves the cost/performance
.28>   characteristics of Digital computers. The strongest message I hear form
.28>   the real world is "We can't afford the number of people it takes to
.28>   keep your computers and applications running"
.28>
.28>   <END HERESY>


Interesting.  When I joined the Company (1979), it was one of OUR messages
that customers would do better with Digital systems than with XXX brand
systems precisely because of the number of people it took to keep XXX
computers and applications running.  We used to joke about how XXX computers
required a raised-floor, glassed-in lab.

Does history repeat itself?

    re: .33
    
    Hi, Tom!  I find I disagree pretty strongly about the assertion about
    SW not breaking.  SW does break, but not usually because of internal
    changes.  SW usually breaks because of the changing environment.  For
    example, SW can break when the OS is upgraded.  Or, it can "break" when
    the customer's needs change.  For example, a customer may be processing
    a database that suddenly becomes too large for the system to handle.
    
    I understand that the usual responses can be that the customer should
    not have upgraded or that that customer should not have tried handling
    a database that was too large.  It can even be proven that the software
    met the customer's original requirements and that, therefore, it is not
    our fault.  But, that is a losing attitude.  It's just that type of
    attitude that can drive a customer to any competitor that feels that
    the customer is always right.
    
    Anyway, back to the original thoughts, I am in the camp that currently
    sees not that much difference between HW and SW.  That is, I pretty
    much accept that anything that can be done in SW can be done in HW and
    vice versa.  True, we know how to run tests on HW (like VAXen) that
    aren't yet available for software.  But, much (if not the majority) of
    this testing is (or can be done) in SW.  That is, the VAXen I have been
    involved with undergo most testing before any prototyping is done.
    This is done in simulation.  I fully expect that in the future the
    emphasis will shift from simulation to formal verification methods for
    HW using the same fundamental concepts used to formally verify SW.
    
    Steve

    Re: .-1

    I have heard the "SW breaks when its environment changes" argument
    before.  That does happen, and some good examples involve using VMS in
    much larger physical memories over time.  But the argument misses my
    point.  The SW has not broken; the changing environment has merely
    revealed another design error due to inadequate testing in the first
    place.  HW breaks because the HW itself has physically changed due to
    use, not because its environment has changed.

    As far as formal methods replacing HW simulation, that may be possible
    in some cases.  Tim Leonard, among others, has been doing work on
    formal specifications that would permit such testing.  But until our
    specifications, both HW and SW, consider formal testing at the time the
    specification is determined, formal methods will not become a useful
    tool and simulation will continue.  Even for a specification as
    thorough as the VAX architecture, there still remain problems that make
    formal methods extremely difficult if not impossible.  Perhaps the
    Alpha spec comes closer.  Other specs are so far away that formal
    methods are nothing more than a gleam in someone's eye.
    
    Nit:  According to the legal department, the term "VAXen" should not be
    used even internally; use "VAX processors" instead.

    re .35
    
    Ah, but we hadn't invented VAXclusters then!

    The point of -.1 is that VAXclusters have tipped us over into a more
    difficult system management/programming class?  There certainly is some
    truth in that, but did it go so far as to get us into trouble in the
    customer expectations arena? -- Fred

    Amazing.  Good points.  Concerned and caring people.  Good ideas.
    Bright people.
    
    Does it look familiar?  It's DEC.  Discussions about "is it software or
    hardware?"  It's bits and bytes and lines of code.  It's putting your
    feet in tar.  It's jello.  It's defend the turf.  No wonder the company 
    doesn't move.
    
    Some have mentioned it.  It's REQUIREMENTS!  Meeting CUSTOMER
    REQUIREMENTS!
    
    What are customers buying today?  Why?  How is the competition meeting
    those needs?  What do customers still need to buy? ......
    
    When we know those answers, then maybe a reorganization will make
    sense instead of more birdcage management.
    
    Oh, someone actually did do some work in this area and found out that
    we spend (approximate numbers) 60% of our selling effort on 25% of what
    customers are buying and 40% of selling on 75% of what customers are
    buying.  Why?  Partly because that's the ratio in which Digital makes
    it and is the traditional (old) market niche.

>re: .26
>
>> Why isn't it reliable or predictable?  People have proven
>> that it can be.  
>
>Could you please give specific examples?  My understanding is that this is
>only true in very specific problem spaces, or for significant increases
>in development costs.  I'd love to learn about success stories that have
>direct relevance to our development process.

Motorola seems to have done it.  Many Japanese software companies
seem to have done it.  I recommend that you contact Bill Wright or one 
of your local software quality councils for specifics.

and from .29:

>    Software isn't as well-designed in DEC as hardware because the methods
>    used are rather different. CASE tools would help, but common sense
>    helps. I went to the Six Sigma for software course last year and heard
>    all the good stuff that I did through sheer common sense 17 years ago.
>    
>    Hardware works. It's reliability is high. 
>    
>    Software IS different. 

So what if it's different?  It's also significantly SIMILAR to hardware
and other areas of high tech.
The fact that ANYBODY has succeeded is any field so closely allied 
to one's own should raise flags that there are ready improvements to be had.

This was my point about divisiveness.
If we all instantly dismiss others' successes as due to irrelevancies,
we're missing an important opportunity to learn from what are or could be
similarities.

Here's a free one you can use the next time a product one-plus is suggested:

  - Hardware response:  We can't start that now, we just entered layout.

  - Software response:  We can't start that now, we just started coding.

No, it won't always work, and it shouldn't.  Hardware design and concept 
flaws are uncovered during layout, and they need to be revisited before
proceeding.  Real design and concept flaws need to be addressed when
found, but the (possible) similarity of processes should be used as guidance
to what succeeds in other disciplines.

- tom]

    re .41: I think the point being made by some is that software as a
    business needs to be liberated from servitude to the business of
    pushing iron.  Putting all software engineering in one organization
    isn't necessarily the right way to go either, but I don't think anyone
    is arguing that all software engineers should report to David Stone.
    From that perspective I can rationalize VMS not being under Stone.
    
    It was one of my previous managers (he still works here) who first said
    to me that "Equipment" was our middle name.  Perhaps we are finally
    waking up, but maybe it's just panic; I don't know.  I have a lot of
    sympathy for the divisionalization suggestion.  However, I'm not sure
    that a Digital Equipment Corporation with emphasis on the "equipment"
    can survive all by itself; if it did, it probably would have to be a
    much smaller company, maybe the size it was when I joined DEC in '76,
    who knows.
    
    Maybe that's the point of the latest reorg.

    re.42 >the size it was ...in '76
    
    Is that so bad? DEC today is in a unique position. We're not (and 
    never will be) big enough to be another IBM, all things to all
    customers. We're too big to be competitive against the fast-and-
    focused niche players. We've got one foot in each arena, and we're
    losing both fights. We don't have an identity, a clear, concise,
    simple message tht says, "We are DEC, we do x." Failure to create,
    maintain, and stick to that identity is killing us. 

re .41 and .42

   Our size in '76 was changing so fast that we were out of
   control and knew it!  It was one of the first things
   impressed on me when I joined DEC.  My boss, my peers, and
   our bosses were all talking about how we were growing too
   fast for our own good, how the infrastructure couldn't keep
   up, how our values were being diluted.  To my knowledge, we
   never made up for that mistake.
   
   Ultimately, our inability to change as fast as the market and
   the competition is what is killing (has killed?) our
   competitive edge.  We carry a bureaucracy that, like a
   turtle's shell, slows us down.  We have no _modern_ internal
   communication "system" (a network and a phone-book do not
   constitute a "system").  So we fiddle around while the
   rabbits can loaf past us.  The only way we can win is if the
   rabbits go to sleep!
   
   A single message is right for an integrated company that is
   trying to do just one thing.  We are not that company.
   Multiple messages are great for multiple companies that are
   not likely to have much cross talk.  I know of no situation
   in which a multi-faceted company like Digital can communicate
   "at random" as we do and not generate widespread confusion.
   Maybe that confusion is deliberate.  It certainly causes a
   lot more soul searching than a single tops-down message
   would.
   
fwiw,

   Dick

    So what does a modern communication system consist of?

    My favourite definition is "the means to make a decision before our
    competitors do".

Re:                 <<< Note 1852.40 by WR2FOR::GIBSON_DA >>>

>				Discussions about "is it software or
>    hardware?"  

Definitions from my Dave Barry daily calendar for today:

	HARDWARE -- where the people in your company's 
	   software section will tell you the problem is
	SOFTWARE -- where the people in your company's 
	   hardware section will tell you the problem is

-  David

    Re: Communicating a single mission statement
    
    I wrote the folowing TV ad and submitted it to our
    advertising group.  My goal was to address one of DEC's most 
    immediate and pressing problems -- creating a coherant image 
    of what we do.  An image the world-at-large can identify with.  
    Catch phrases like NAS and "Open Advantage" fail to galvanize an 
    image, and so they seem vague and disconnected -- maybe even 
    proprietary.  We need to provide context.  Does this ad hit
    the mark?


Goal:          To capture succinctly and in 35 seconds the essence 
               of DIGITAL's mission -- our product strategy.


Story board:   Someone at a workstation in an office cube.  DEC
               workstation.

               Pan out from above -- highlight the cube border in a
               flash of white light, then iconize the workstation.  Use
               a luminescent white light for the icon.

               Shift angle to office adjacent as camera continues 
               to pan back revealing office layout of cubicles.
               Window into the adjacent office to show someone working at a 
               PC clone -- Dell machine.  (Effect: Zoom out from cubes with 
               simultaneous window into office.  Mimic effect of opening 
               or closing a window from an icon -- rapid, concentric 
               rectangles.)   

               Split second later, iconize the second office and connect
               it to the first with the appropriate network symbol 
               (luminescent).

               Continue panning back, flash into contiguous offices
               to show the complete spectrum of products we produce
               and/or network -- rapid-fire montage or catalogue --
               then iconize and interconnect them into the configuration
               of cubes.  

               Pan back to show additional cube configurations and computer 
               rooms on a floor of a building.  Individual office icons 
               resolve into points of light interconnected with luminescent 
               network symbols 

               Keep pulling back and iconize each cube configuration 
               and computer room, interconnecting them with the appropriate 
               network symbols to interconnect an entire floor.

               Pull back to show floors in a building.  Iconize each floor
               into a web of light interconnected with luminescent
               network symbols.

               Pan back to show multiple buildings, then iconize
               and interconnect.  Keep pulling back to show buildings
               in various locations, interconnected by appropriate
               symbols.  

               As scale increases, icons reduce to points of light
               whose relative scale indicates the icon level (office,
               floor, building).  Constellation effect.

               Picture continuously transitions towards symbolic (icon) 
               representation -- real video image progressively drops 
               out, but all icons are explicitly accounted for.  

               Dim final context queue (globe of interconnected icons) leaving 
               interconnected network of illuminated icons.  Global network 
               shown as a web of light in the shape of a brain -- slowly 
               rotating -- against a black background.

               Hold for a moment, then fade in the image of the
               person sitting at a workstation back in the first office.  
               Superimpose and align the network image on the person's head.  
               Fade out the network image and resolve into the real image 
               back in the original office.
 
               Have the computer-generated DEC logo rotate into
               view -- each letter separate, rotating simultaneously
               (the PBS logo) -- at the bottom of the screen.  Voice over,
               "Think as one."

   Re:    <<< Note 1852.45 by SSDEVO::EGGERS "Anybody can fly with an engine." >>>

Well, to start out with, the "system" includes the people who
communicate and the procedures they use to do so.  

The "system" identifies some messages as needing immediate
distribution to some parts of the audience and delayed
distribution to others.  

The "system" can always deliver a message addressed to:

   Secretary to Site Manager, @XXX, or
   Personnel Compensation and Benefits Administrator, @YYY.
   
The "system" can provide ancillary information like, "a list of
all salesmen active on the XYZ account within the past 60 days",
or "last quarter's revenue" or "next quarter's forecasted
revenue" or the current population.

In summary, all information about the corporation, its
activities, its resources, and its people is accessible to "the
system" and, given appropriate security, can be distributed
either routinely or on an ad hoc basis with a minimum of "cut
and paste", "task switching", or "mailroom activity".

The best demonstration of Digital's ability to help its
customers would be to get its internal information systems act
together, not as a collection of point applications, but as the
information backbone of a modern multinational corporation
engaged in manufacturing, engineering, software, and integration
businesses.  

That entails a vision of information and communication as a core
discipline that a large company must master, just as it must
master manufacturing management or sales management or personnel
management or financial management.  It entails a lot of things
that are practically impossible today (that is, anyone could
find reasons to give up) but offer tremendous competitive
advantage if we are successful.

fwiw,

   Dick

I like it!

    Re: .48
    
    	Sounds great!   I love it!!   Lets work out the details and
    produce it.  How about we get it ready for the Olympics? Or maybe
    sooner.
    
    Whoops!  I was just dreaming.  It makes too much sense.  We can't do
    it.
    
    	...rich pack

    re .43:
>    re.42 [me]
    >the size it was ...in '76
    
    >    Is that so bad? 
    
    Personally speaking, no, that's not so bad at all.  I'd rather DEC be a
    company that's fun to work in than an unsuccessful imitator of No. 1. I
    remember the DECUS symposium where in her keynote speech the late Adm.
    Grace Hopper (who was yet to retire from the Navy at that time) chided
    DEC for forgetting where we did well (in minicomputers) and going down
    the path we did take.
    
    Be that as it may, we can't turn back the clock.  The Old DEC is gone,
    and we can't go back to it now.
    
    --Simon

When I interviewed at Dec in 1972, the guy who interviewed me (Nick Pappas)
noted that Dec was really a publisher with a small hardware manufacturing
capability.

I believe that, for a while in the 1970's, IBM and Digital published
the largest amount of new material of any publisher, excluding the
telephone company catalogs and government.

Martin.

    Then lets start right now, and proceed to make a NEW DIGITAL!!!!
    
    Dave
    

	re .48:

	Great idea for an ad! I would run it tomorrow "if I were Ken for
	a day". Sounds as impressive as the HP one a few years back which
	showed office staff as computerised robots "zapping" information
	to each other with pulses of laser light - if not more so.

	re .49:

	Dick, you can't make all that information available to people
	without proper safeguards. Nobody would have any incentive to
	go to meetings to try and find out what's going on. Managers
	wouldn't be in a position of strength, hoarding their precious
	secrets and rationing them out to those who approach them with
	the correct obsequious manner. Knowledge is power - HOARD IT!!

	For years now I have been understanding, with growing horror, the
	appalling state of our internal information systems. Critical
	strategic decisions are being made weekly on information which
	could be quite inaccurate (up to +/- 50% is one estimate I've
	heard).

	One facility I'd like to see right now is a list of account
	teams indexed by customer name, available instantly like ELF.
	Well OK, available instantly. Would you believe that if you
	get a lead for a particular company, the only ways of contacting
	the account team I know of are

	(a) Through the famous informal "network" (i.e. about 14 phone
	    calls)

	(b) By going to the group whose manager "owns" this information,
	    and cajoling him or his secretary into letting you access
	    "his" system. And that's after you've used the "network"
	    to find out that such a group and system exists!

	The impact in terms of lost time is actually rather lower than
	you might think - the main effect is that people don't even try
	to contact account teams in the first place.

	/Tom

    re: 55
    
    	tree hugging, especially concerning information is probably even
    more rampent these days, despite the plee's to stop it. Fear, and there
    seems to be plenty of it causes people to squeeze even tighter. There
    are certainly some big obstructions that need to be cleared.
    
    

    The real reorganization when it comes will transform Digital into
    something more recognizable to people familiar with other large
    companies.

    A CEO to create a vision for the company and the general structure  and
    segmentation for the company, and an extraordinary judge of character
    for his divisional vice presidents.  Stability for the structures and
    quick response to changes in the business environment. (It seems we now
    have the inverse)

    Vice Presidents who have honest books of account, and make decisions
    about entering businesses (and leaving them), hiring (and firing),
    participation in DECWORLD (and non-participation...).  Financial
    accountability and none other.