Conference 7.286::digital

    Why don't we learn? because all too often we simply turn our collective
    backs upon the past.
    
    Those who do not know history are destined to repeat it.

    I have to agree with Simon.  While the ELF-bashing note is kinda fun
    (haven't had that much fun since bashing the DECworld 87 registration
    system!), I hope the ELF V2 developers are listening, because in
    addition to bashing & flaming, there are some good comments and
    constructive criticism there as well.
    
    In terms of not learning from past mistakes, I think a classic case of
    that is the various DECworld/ville registration systems.  Europe has
    used pretty much the same system (with enhancements) based on ALL-IN-1
    in 85 and 86.  (Not sure what they used in 88).  But instead of trying
    to learn from them, we here in the US invent our own *from scratch*
    every year; 86 written in BASIC, 87 in COBOL, and making the same damn
    mistakes that have already been made in prior events.
    
    I don't understand why "baton-passing" needs to be that difficult.
    
    Jon

    Being in the field since the number of Software Specialists worldwide
    climbed above two digits, I see this problem occurring quite common
    among our customers.
    
    What I think happens is that _constraints_ are imposed on the
    developers regarding standards, tools, environments, etc. and _user_ is
    not as articulate, involved, etc as whatever forces are brought to bear
    on the developers.  "Success" therefore is meeting constraints, not the
    definition of "success" as defined by the user.
    
    The marketplace imposes a discipline on poor products, no one buys
    them.  Unfortunately, when you are talking about a tool that regulates
    access to name, address, phone, etc. of thousands of employees, or
    product cost and profitability data, or any other sensitive data, there
    can't be an "internal marketplace".
    
    Thankfully, the number of software products "forced" on Digital
    employees is small, even then, there's resistance to them.

    NIH (Not Invented Here) Six years it was a problem.  Today, the problem
    is almost the opposite, if it was invented by DEC it cann't be any
    good.

    IOS (Invented Out of Sight) Technology transfer is a MAJOR problem. As
    the average DEC employee gets older, they want to spend more time with
    their SOs and children. At the same time there is more technology to
    transfer making it harder to keep up. And then schedules and budgets
    have tightened providing less time and money to go out and actively
    seek out new technology. 

    Golden Rule (He who has the gold rules) People build what the person
    who signs the checks says to build, even if it is dumb. Managers are
    telling engineers to build things to protect the manager's turf.
    This is also seen in the statement, ABC might be better but we do XYZ ,
    so go do another XYZ.
    
    NOGAD (No One Gives A Dam) The "customer" is locked in and doesn't have
    a choice so we can do anything we well feel like. 
    
    And of course even the worst of ideas, plans or whatever
    "Seemed Like a Good Idea At The Time".

    mike

Re .0:

Part of the problem may be a reward and recognition system that
doesn't fully appreciate the value of learning from our predecsssors 
and using their work.

Quick quiz - In each of the following pairs, which phrase would look 
more impressive in your next performance review (or on your resume)?:

   "designed new utility"    "enhanced current utility"

   "wrote new manual"        "revised previous manual"

   "created new procedure"   "modified existing procedure"

In many cases, the process of revising (modifying, borrowing, adapting,
reorganizing) can involve more creativity than starting from scratch.

P.S. This is not directed toward ELF V2 or any specific project. I'm 
merely commenting on the general issue raised in .0.

    re .4;
    
    You forgot Maslow:  "If the only tool you have is a hammer, you tend to
    treat everything as if it were a nail."
    
    If you tell a bunch of VTX gurus to come up with an ELF system, guess
    what you get?
    
    -dave

    Oh leave the ELF stuff in the ELF note. Simon makes a valid point: how
    can we ensure that experience is propagated?

    I second the impressions that we don't learn from our collective past,
    though I won't cite specific examples.  I lay the blame at the feet of
    matrix management, and also to the fact that Digital is a large and
    dynamic company.  Some kinds of information we get in such abundance
    that we don't read it.  Many people are new here, so their experience
    isn't relevant.  (I know my procedures cold, but they're not Digital
    procedures 8^)  People come into the company with great ideas, and
    sometimes they try to get them implemented.  (I've tried a few myself.)
    The result can be the "standard-du-jour" effect.
    
    In the project I'm on, it often seems as if no one has ever actually
    gone through the entire development process before.  That includes the
    engineers, the managers, the writers--everyone!  This is a large
    project, with scores of people involved.  I know for a fact the
    experience and knowledge is in the group, somewhere.  Yet I get the
    distinct impression we're groping for procedures.  Maybe I feel that
    way because people make them up anew at every baselevel.  Or maybe it's
    because people are looking to me to tell them what to do, when I
    haven't gone through the procedures myself before.  The blind lead the
    blind...
    
    I've participated in a post-partem for a product release, but I don't
    know that the lessons learned there were ever passed on outside that
    development group; I've certainly never heard of post-partem results
    from any other projects.  (Does that mean they're not passed on--a
    foolish notion!-- or was the one I saw the first and only release
    post-partem--which reinforces my point?)

    I have worked in the field on hardware for many years.  In the
    seventies it seemed that every new system had the same old problems
    when it came to maintenance, fans impossible to change, power supplies
    that were unreliable, etc.  From the late seventies on, starting
    with the KS10 and the VAXes, things started getting better and most
    of the new systems comming out today are very easy to maintain.
     What happened was a directed and concerted effort by engineering
    and field service to change things and not repeat past mistakes.
    
    The same methodologies need to be applied to software.  VMS doesn't
    appear to keep making the same mistakes.  Is it because of consistency
    of people and a continuing effort?  Do they have a "standards document"
    that they write to?  What about quality control?  But then again,
    VMS isn't a 'project'.
    
    I suspect one reason projects like ELF have problems is that the
    original project was a one time shot and there was no vision passed
    on or available to the poor souls who were told to update/re-do
    it.
    
    Irv Waldo

    When an organization becomesas large as ours, matrix managment and ad
    hoc teams can be a real obstacle to learning-from-the-past, as the work
    group has no SHARED past.  The various team members can try to pass on
    their inidvidual past excperience in the form of war stories or what
    have you, but this somehow  lacks the immediacy of "Remember how badly
    we screwed up on this issue when we did BLIVIT version 1.0?"
    
    Unfortunately, there doesn't appear to be any simple answer to the
    problem.  We could document development efforts (inclusing post partem
    conclusions) religiously, but that wouldn't necessarily make the
    information any more accessible than it is now, tucked away in people's
    heads.
    
    Maybe we need to build some sort of monstrous expert system that
    everyone could contribute to over time.  It could become our "corporate
    memory ;^)
    
    -dave

One reason we don't consistently build from an existing base is that we
aren't goaled that way.   Typically we set 'discrete' goals.
By that, I mean we pick an attribute and assign a numeric measure on it
as a target.   We want XYZ mips or ABC fresh lot yield or a car that can go
75 M.P.H., etc..

A more reasonable way to encourage building from a known base is to assign goals
that are 'dynamic'.   Dynamic goals are goals which are set as incremental
targets to be accrued on top of an existing attribute.  You might want
10 mips per year improvement or fresh lot yield to improve 5% per year or,
if a car, you might want 10 M.P.H. increasing as a square :^).

In my opinion, discrete goals encourage discrete projects.  That is, projects
will tend to be conceived in one planning cycle for the next planning cycle.
If it's even remotely possible, the planner will squeeze the work to fit the 
length of that cycle.   Dynamic goals, on the other hand, can be structured to
encourage continuity across planning cycles.   It's possible to plan in one 
cycle and set a goal that will be valid for many cycles.   In many cases
you might need only minimal intervention between cycles to revisit goals.

It is very difficult to fund a dynamic goal in an environment with short
planning horizons.  

    
    REF: VAXnote 960.10
    
    >> <Unfortunately, there doesn't appear to be any simple answer to the
    problem.  We could document development efforts (inclusing post partem
    conclusions) religiously, but that wouldn't necessarily make the
    information any more accessible than it is now, tucked away in people's
    heads.
    
    >> <Maybe we need to build some sort of monstrous expert system that
    everyone could contribute to over time.  It could become our "corporate
    memory>
    
    In respone to this reply, my employee involvement suggestion is that we
    should indeed immediately begin creating a monstrous expert system,
    using our hyperinformation technology, that will incorporate the
    thoughts, knowledge and intelligence from our past experience, PLUS
    ongoing input from every employee and customer, and every tidbit of
    technological information available.
    
    Creative intuitive thinking that makes quantum leaps over "the way its
    been done before" typically is derived from simply and suddenly
    "seeing" patterns of connections (often of unrelated items) that no one,
    anywhere on earth, has discerned before.
    
    With hyperinformation technology, millions of "pieces" of textual
    "thoughts" and knowledge and intelligent thinking and, yes, opinions,
    can be encoded, randomly, along with past experience, with the ability
    from this new technology to search and access by key words and phrases. 
    Moreover, one can begin pulling unrelated inputs, and accelerate the
    process, normally done up to now within the human brain, of arriving at
    creative intuitive thinking -- new patterns, which lead to ideas and
    actions that no one has considered before, where if implemented, have a
    high probability of being accurate and of making significant quantum
    leaps, affecting both technology and actions, such as those we make in
    growing our markets, customers, revenues, margins and profits.
    
    I submit that whoever in a given industry does this FIRST will own that
    industry because from then on, nearly all company actions, top to
    bottom, will have a higher probability of being MORE accurate and
    correct than any that would be done by any competitor relying on the
    "best guesses" of a handful of people affecting any given action
    
    In addition, I submit that if JAPAN INC starts doing this first (highly
    likely since they adopted Deming's successful statistical approach to
    quality and change when most companies in the United States have
    rejected it for 45 years) then Japan's future "business" success
    worldwide will make its present success pale by comparison.
    
    Digital, in my opinion, and as an employee involvement suggestion,
    should begin immediately to utilize this new technology for its OWN
    INTERNAL success in building a more successful Digital worldwide in
    the decades to come.
    

    re: 960.12 Monstrous Digital Expert System
    
    sounds like Vax Notes to me

    Notes, while providing a necessary medium for exchange of current
    information, would not serve well as an "archival" medium.  First,
    notes is (are?) too compartmentalized.  I can search all the
    conferences that relate to my problem/project, but the insight I need
    may be hiding in a quite unrelated conference.  Secondly, without some
    sort of global indexing, the sheer volume of notes dooms any attempt to
    connect and correlate experience across a range of technologies and/or
    geographies.  Finally, notes conferences (the active ones at least)
    tend to get archived periodically, further compartmentalizing the
    information.
    
    Notes may contain the raw data of our experience, but we need a means
    to turn that raw data into information.
    
    -dave
    
    

We could start with finding out and listing the most common screw-ups we've
made in the past and listing these as potential problems in the project 
procedures so we don't repeat history yet again.

Regards,  Geoff.

This is a really good topic, and I agree with all the preceding replies (no,
I'm not sick!) :-)

Here's yet another possible contributory factor (suggested by an ex-IBM person
who sits near me, in a recent coffee-machine session): despite all the fuss
about "solutions" amd "business", Digital remains firmly a techy company. Most
of us are techies, and that includes most of the managers (well, count Ken in
for a start).

Sound good? Well, not really. Because the syndrome is this: suppose there is a
need for a new system, everyone's reaction is:

	(1) Hey, we can do that with computers! (probably VAX computers)

	(2) I'd do it with Datatrieve (/VTX/ALL-IN-1/COBOL Generator/RALLY/...)

In other words, precisely because almost everyone has fooled about with software
at some stage, we're incapable of saying "this is WHAT we need, we won't think
about HOW yet for a while". Moreover, whereas the people who specify and pay
for a system should ideally say "Here's the requirements, here's the money, and
I want it by Q3", they do tend to say "and it must run on MicroVAXes networked
with X.25" or some other set of essentially inappropriate constraints.

If we could get to the end of Phase Zero without being committed to some
specific implementation, perhaps the implementors would get a chance to look
around for the best existing base. Ask the software engineers in SDT at
Spitbrook; they'll tell you they JUMP at the chance to reuse something that
already exists. "Borrowing code is 100% productivity!"

/Tom