Conference 7.286::digital

    
    	I doubt that Radio Shack would be interested in doing that
    	since they already make their own and there's not enough
    	margin in our PC's for us to give them enough of a discount
    	to make it profitable.
    
    	And, I don't think that solves the problem either because
    	I don't think they make too many sales calls outside the
    	store for someone who wants to buy one PC.  I think you're
    	referring to the plumber who wanted to buy a DEC PC and
    	couldn't get a DEC sales rep to call on him to sell him
    	one.
    
    	Unfortunately, there's a real problem for anyone (us or
    	Radio Shack) to provide that kind of direct sales coverage
    	for low margin products like PC's and make it profitable.
    
    	And I'm not sure Radio Shack provides much of an advantage
    	to us even if we were able to strike some kind of a 
    	mutually-profitable deal with them.  I'm not sure they're
    	a very strong force in the PC market anymore.
    
    	Even Radio Shack is going to have trouble selling PC's	
    	through low volume retail outlets with their overhead
    	structure and competing against some of the high volume
    	discount retailers and mail-order operations that compete
    	in that market.
    
    	Chuck
    

    
    What about through another place like Computer World or it's equal?

    Isn't this what the 1-800-PC-BYDEC number is supposed to accomplish?
    
    Customer's can not only put in a small order but they can also get at
    least SOME technical advice and, once delivered, service is handled by
    the local office.
    
    Sounds like all they would get from Radio Shack or from Computerland.

    (800) PC-BY-DEC is the hotline for those small customers to call,
    and if anyone in a Digital field office gets a request from a
    small sized customer, the first thing that person who answered
    the phone does is offer to mail to the caller a catalog for
    PC-BY-DEC.  There should be extra copies of this catalog in
    lobbies of our offices.  Small-sized companies may get a
    visit from a DEC sales rep, but only after a qualifying sales
    telephone call is made to determine the potential for the
    opportunity.  If the dollar volume is just not there, then
    the PC-BY-DEC catalog will just have to do.  Remember, DEC
    must remain profitable and sales reps are too expensive of
    a resourse to chase after the low dollar volume sales.
    
    -JW-

	Does PC by DEC also do VAX and DEC stations ?

	Documentation ? Software ? etc.


				Mike
				----

    
    What's wrong with CompUSA Store? I have been to that store recently in
    Woburn and there are a lot of computer company names on the wall excpet
    Digital. Can they sell DEC's product from that store?
    
    Kevin
    

    Digital does not sell retail! We tried it back in 1982 and it was a
    major flop.  Mainly because it wasn't done right.  Anyway, new ideas
    are not welcome at this company.  Only the old ways are acceptable.
    
    Rick
    

    Oh, don't get me started on cost of sales.  Listen to this scenario -
    In a district sales office there is one order administration individual
    who does placement, expedites, change orders, interfaces with credit. 
    In other words - "one stop shopping".  
    
    At PCBYDEC they may have lower cost of sales, however, its based on an
    individual cost of sales basis - and this is my gripe.  One person
    takes the order, another person does expedites, another person does
    change orders, and another person is the credit contact.  These are the
    four that I "know" of, there may be more, who knows.  So if you add up
    all the cost of sales for this empire it probably outweighs the cost of
    one person doing it all, who knows, only my humble opinion.

    
    	Re: .8
    
    	What would be interesting to find out, however, is the average
    number of orders processed per week by the one person in the district
    sales office versus the average number processed per week by the
    PCBYDEC folks.  Sure, there might be a 4:1 ratio in the number of
    people, but if the ratio of orders exceeds 4:1, PCBYDEC is more efficient
    on a per-order basis.
    
    							-craig

re: .7                     -< Retail? >-

Actually, we started it a lot earlier than that, didn't we? That would
have been about the time that our "entry" into PC's in general flopped
(ala the Rainbow/DECmate/PRO incompatibility trio), but I seem to recall
that we had retail stores in major markets open before that selling (with
some success) WPS-8 systems and even 11's. Stan Olsen's original store
at the Mall of New Hampshire was open in '78, at least - maybe earlier.

-Jack

>                    <<< Note 1929.7 by MSDSWS::RCANTRELL >>>
>                                  -< Retail? >-
>
>    Digital does not sell retail! We tried it back in 1982 and it was a
>    major flop.  Mainly because it wasn't done right.  Anyway, new ideas
>    are not welcome at this company.  Only the old ways are acceptable.
    
    What makes you think we *aren't* attempting to open retail distribution
    channels today?  The folks up at MKO may have something different to
    say.
    
    Mark.

    Some time ago I was talking with a vendor of ours and he was going to
    buy a PC.  I said that we did have personal computers and software by
    mail order.  I picked up the phone, dialed 1-800-digital and requested
    the catalogue.  I was told to send the request over the tube to
    NEST::ORDER, no problem; I sent the request over the tube.  I wanted a
    copy of the latest catalogue sent to myself and one to the vendor's
    home address.  A week or so later I got a message over the tube that my
    order could not be processed without my badge number, cost center,
    site code, etc., etc. So I resent the request with that "relevent"
    information.  Well its been months now and neither of us got the
    catalogue.  He is real happy with his new machine, it doesn't have our
    name on it of course.  If the new program is like the 1-800-digital
    program, I would say it is destined to fail.
    
    Regarding .4's assertion that sales reps are too expensive of a
    resource to spend time or effort on low dollar volume business.  I can
    see why we are likely to fail in the PC business.  This harks back to
    the attitude that PC's really aren't computers, they are toys.  Real
    machines are $100K - megabucks, with obscene profit margins.  Well what
    do you think will be happening to PC's over the next decade?  They'll
    probably be competing with anything we've currently got at something
    less than 10K.  Yes that sales rep's time is quite valuable now,
    because he/she will be out of work as we fail to compete.  I don't
    fault the sales rep but I do fault the mentality that says, "My dear
    boy, come back to us when you want to buy a real big machine, until
    then don't bother me."  I'll guarantee you if that "boy" is going to buy
    a big or "real" machine in the future, it probably won't be a DEC. 
    He'll remember how he was treated.
    
    If we are going to get serious about PC's, we've got to be the best or
    at least one of the best if it is going to be successful.  If our goal
    is to get across the stream, we've got to do it in one leap or we'll
    surely be all wet.  Going at it halfheartedly will be worse than not
    going after it at all, and will give rise to the self-fullfilling
    prophecy, "I knew we couldn't do, and we didn't."  At which all the
    yespersons will say. "Hear! hear!" and be fully satisfied with their
    omniscience.
    
    The problem IMHO, is that we always were able to sell systems with high
    margins.  This allowed, high overhead, huge bureaucracies, inefficient
    systems and procedures to creep into the business.  We're now reducing
    headcount but I fear we are doing nothing about the problem of being so
    inefficient, etc.  We're losing line workers, engineers, and talent
    which have worked very closely with the products we produced.  We need
    to get rid of overhead!
    
    DAR

    
    	re *
    
    	I cannot believe that this company cannot understand how to, or
    	find a way to, quickyly and easily sell computer hardware, soft-
    	ware, education, or services to a person or company that has only
    	X amount of dollars to spend.
    	
    	We need to spread the word aabout our products to all segments of
    	society, not only the corporate boardroom. Walk into most of the
    	primary or secondary school districts these days, and what do you
    	see? Apple computers on the desks. Or IBM's. Walk into any small
    	(under $1M/year) and chances are the systems that they are using
    	to run their businesses are NOT Digital systems.
    
    	The point is, we need to get more in tune with being able to reach
    	out and touch the average American or European or whomever. The
    	future of this company cannot rest on sales > $500K alone.
    
    	If the "cost of sales" cannot support this, then lower the cost of
    	sales somehow. Don't tell me that it can't be done..other companies
    	are doing it, and eating our lunch in the process. There are some
    	very talented people with some very good, fresh ideas that could
    	make this work, in  this company. Why we are sitting on our hands
    	and not moving forward is beyond me...
    
    	John
    

RE. Note 1929.13            
    
    >	I cannot believe that this company cannot understand how to, or
    >	find a way to, quickyly and easily sell computer hardware, soft-
    >	ware, education, or services to a person or company that has only
    >	X amount of dollars to spend.
        ****************************
    
    There are segments of companies that are immune to the economic cycles.
    The fact is, some segments of company expenditure are being cut or
    eliminated, the area that is left alone or increased is the regulatory
    area.  They all have to spend for environmental compliance. Digital has
    the ability to capture services revenue by telling our customers we can
    help them begin address their environmental problems by developing an
    information technology based solution.
    	
    >	We need to spread the word aabout our products to all segments of
                                              *******
    					All our services and products.
    
    >	society, not only the corporate boardroom. Walk into most of the
    >	primary or secondary school districts these days, and what do you
    >	see? Apple computers on the desks. Or IBM's. Walk into any small
    >	(under $1M/year) and chances are the systems that they are using
    >	to run their businesses are NOT Digital systems.
    
    :TRUE
    
    
    >	The point is, we need to get more in tune with being able to reach
    >	out and touch the average American or European or whomever. The
    >	future of this company cannot rest on sales > $500K alone.
    
    :TRUE
    
    >	If the "cost of sales" cannot support this, then lower the cost of
    >	sales somehow.  
    
    :INCREASED SALES REVENUE IN NEW MARKETS BRINGS IN MORE DOLLARS, AND
    SHOWS GROWTH. REDUCING EXPENSES ONLY IDENTIFIES NO GROWTH!
    
    >                   Don't tell me that it can't be done..other companies
    >	are doing it, and eating our lunch in the process. There are some
    >	very talented people with some very good, fresh ideas that could
    >	make this work, in  this company. Why we are sitting on our hands
    >	and not moving forward is beyond me...
     
    We as a company can only grow if we seek and capture busines in new and
    old areas. The task is to identify those segments that are spending the
    most and sell our portfolio of services and products.
    
    	hy

    >     <<< Note 1929.14 by CTOAVX::BRAVERMAN "Perception=Reality" >>>
>                             -< Follow the money! >-
>
    >    :INCREASED SALES REVENUE IN NEW MARKETS BRINGS IN MORE DOLLARS, AND
    >    SHOWS GROWTH. REDUCING EXPENSES ONLY IDENTIFIES NO GROWTH!
    
    First, COSTS include ALL costs (including selling costs), NOR is
    revenue less discounts and allocations.
    
    There is a simple financial principal that is applicable, here. If it
    COSTS $1.50 to sell a product that bring is $1.00 NOR, you lose $0.50
    for each and every sale.
    
    There is an advanced Financial principal that says, "The more units you
    sell at a loss, the closer you get to chapter 11."
    
    When a company is losing almost $100 MILLION per month.........

    The crucial fact that our strategy doesn't address is the
    ever-expanding market as price/performance drops.  
    
    Just consider that for every business, there is a break-even point in
    computing power, that point at which a computer plus software plus new
    employees or re-training becomes cheaper than today's way of doing
    business.  
    
    Eventually, even a business that does not grow will reach the point
    where the computerized way of doing business is cheaper and more
    effective than people.  At that point, someone who was not part of any
    of our markets becomes a potential customer just by virtue of the
    price/performance trend.
    
    A growing business will follow the same pattern, but faster.  We are
    missing the opportunity to be these customers' first computer vendor
    and to piggy-back on their success to supply them with more and better
    hardware, software, and services as they grow, often at rates we no
    longer enjoy, 15-25% annually.
    
    Our current strategy is to sell to the largest companies who have
    already stopped their explosive growth, where decision making is
    bureaucratized as it is here, and to be tied to the 3-8% annual growth
    rate normal for such companies.
    
    Somehow, I doubt that the Digital of 1970's could have become the
    Digital of the 1990's without the growing customers we used to support.
    Maybe we have so many "big company managers" now that we can't
    understand a small growth company any more.
    
    fwiw,
    
    Dick

re: .13, John
>             -< Oportunity knocks and we ain't answering the door >-

> Walk into most of the primary or secondary school districts these days,
> and what do you see? Apple computers on the desks. Or IBM's.

And if you'd walked in there twelve to fifteen years ago you would have seen
VT52's or VT100's attached to PDP-11's running RSTS/E.

We could have had the whole thing sewed up if we'd been concentrating on
the same things Apple and IBM were at the same time, I suppose. Kind of
sad in some respects, but I guess that's subject matter for another note.

-Jack

    In reply to a topic on workstations, I entered the below; however, it
    seems that it's also relevent to this topic:
    
    About 3 years ago, Don McInnis wanted to know how to increase sales of
    workstations, so I told him. He wasn't interested in my reply, but here
    it is again, because I believe it is directly relevent to this topic.
    
    (In essence) I explained that in 1978 I sold the first true
    workstations on the market (the Tektronix 4051, which competed with the
    equivalent HP 984X series). This thing had an 8-bit micro, tape or disk
    mass storage and a 1024x780 resolution vector-driven graphics monitor,
    with software for CAD through to graphing, from the company which at
    the time owned about 90% of the computer graphics market. How they lost
    that market share is another story....
    
    To shift this rather expensive beast (about $10K each), I had two
    units. One for revolving demo loans, the other for my car. I took this
    thing everywhere and sold it by demonstrating it off the tailgate.
    
    In this way, I sold this unit and related products to the tune of one
    million pounds (at the time about $2.4 million) in my first year. Good,
    by the way, but not the best sales figures.
    
    How is this related to Digital and workstations?
    
    I firmly believe, through experience, that a separate sales and support
    force is needed to move this type of product. For maximum efficiency, a
    sales rep needs to have broad technical knowledge of all the major
    applications for workstations, from CAD/CAM through financial software
    products, and to have demonstrations of a good few of them. This person
    must have access to the best and fastest units and be able to loan them
    on short-term demos. This person should be able to react to sales calls
    within hours, and be able to quote all specifications and prices.
    
    In short, a workstation sales rep needs to focus on this business and
    be given the tools to sell. If trained properly, there should be only a
    need for about one support person for every 7 or 8 reps, because the
    reps should know their product so well.
    
    But I don't see this happening, because our existing management seem
    hell-bent on having a huge monolithic sales force, supported by
    general-purpose people (who usually only know VMS and All-in-one),
    sales reps are told only to follow huge opportunities which have slight
    chance of maturing into orders, and have lost sight of the end
    customers because they have to know something about everything in
    Digital's awesome price list.
    
    In the workstation business, from little acorns do mighty oak trees
    grow. And that means following the small orders, a few units at a time.
    When the customer is happy (and by that I mean the end users, not the
    purchasing VPs), they will order more.
    
    And that's when the big opportunities become winnable.
    
    One only has to sell 100 workstations to make up between $1 and $2
    million in business, an easy figure for young, hungry sales reps with
    the right focus. Those 100 units could become 1,000 in two or three
    years.
    
    Ray

    Ref. .12   I too ordered the catalog over the tube and subseqently
    received the message that badge no., cost center, etc. were required.
    They were provided when the order was placed.  I placed a phone call to
    the number that was provided on the subsequent message and was told
    that all the required information had been received and my order was on
    file.
    
    It has been 7 weeks since the order was placed and I have received
    nothing.  The real world does not tolerate this type of response for
    very long.
    
     

	You can phone   DECdirect, they even take credit cards, for orders less
	then 50 quid they have a handling charge.
	(Hardware and/or software catalogue available)
	We sell through CSO's and VARS.
	The above sold over 50% of our sales in the UK this year.
	The SME company (some of Keinzle and Philips) is targetted at selling
	to Small or Medium size enterprises.

	Heather	 

    I think that this note was originally about marketing and selling to
    smaller businesses.  There is really a two path question: does the end
    user know what they want and looking to order the product/solution at
    the lowest cost, or do they have a business problem and they don't know
    where to turn?  Both approachs turn out to involve third
    parties/indirect channels, not the computer vendor.
    
    For smaller systems (W/S and below) customers primarily buy computers
    from third parties: stores, applications resellers, etc.  This is to
    have the computers available close to the customer, which no vendor
    including IBM can afford to do - they need to have a borad distribution
    strategy to succeed.  IF the
    customer knows they want a laptop and want to try and shop - they go to
    a store (or superstore like COMPUSA) and do just that.  Mail order,
    PC's by DEC, etc. assume the end user has made the product and vendor
    decision.  10% or less of PC's are sold this way, through mail or
    phone.  Customers often want to touch before buying.  For example -
    DELL computer which started with telehpone ordering and catalog now
    also sells its computers through Staples Super stores and COMPUSA -
    this where their customers can see their systems in use.
    
    Most small business buyers need help and support beyond what a vendor
    can provide, often coupled with a larger investment in the applications
    software than the hardware itself, therefore end users work with
    application resellers (aka Value Added Resellers or VAR's) to obtain
    the total solution they need from a single source.  DIGITAL's approach
    to the Small and Medium size companies is to sign up VAR's in many
    industry niches and work with them to sell our products/services as
    their primary line - they usually carry 2-3 lines.  If you attended
    DECWORLD and went to the SME area - you saw about 40 VAR's
    participating with solutions for restaurants, retail point of sale,
    doctor's offices, etc.  Many of these VAR's provide service and support
    of their applications, while they resell DIGITAL products and support
    services.
    
    DIGITAL has shown that it can NOT be all things to all people.  Where
    we choose to not market and sell directly, we use resellers and other
    CSO's to bring our products/services to a wider market.  To the extent
    to which we work well with these VAR's and CSO's, we will be more or
    less successful in the SME area.  We simply do not have the resources
    nor capital nor time to write small business applications from scratch
    and provide the total solution ourselves.
    
    

    re: .22
    
>    everyone who doesn't even know how to use computer.  It worked, AS400
>    really sold well in the expense of VAX.
    
    Thanks, I needed a good laugh :-)
    
    Please provide the following:
    
    Total number of VAX machines replaced by AS400 machines.
    Total number AS400 machines replaced by VAX machines.
    Total number of sales where VAX machines and AS400 machines were bid.
    Total number of sales above where the AS400 machine won.
    
    Bob
    

    re .24 re .22.. 
    >Thanks, I needed a good laugh :-)
    >Please provide the following:
    
    Total IBM revenue generated annually by AS400:  14 $BILLION ..
    
    .. still laughing ?
    karl

	... and let's not forget that the as/400 (thanks to the s/36
	and s/38 folks) had one large number of applications ...
	and, in fact, this is what VAX and as/400 have in common
	(other than the fact they both use electricity).

	Because both VAX and as/400 are proprietary, neither has had
	much luck replacing the other.  First guy in gets the lock.

	-- gerry

    re: .25
    
    >Total IBM revenue generated annually by AS400:  14 $BILLION ..
    
    Other than being big, that is a meaningless number.  Most of that could
    be System/3/34/36 upgrades.  It doesn't tell me anything about how much
    of that came at the expense of VAX sales which is what .22 is claiming.
    
    Bob 
    

    
    I've come up against the AS/400 4 times in the last year and a half at
    my account and I've successfully sold a VAX (yes, VMS) every time. The
    trick is in relationship.  I've said it before.....if the executive
    KNOWS YOU WILL MAKE IT WORK, make him successful, he'll spend his money
    on you everytime.  AS/400 never gets past the first meeting anymore....
    People know if you "do it with DEC, it gets done."
    
    Re a few back, the sales basher....
    
    Two can play at that game!  :)
    
    The sales force is good, for the most part.  There are some who need
    motivation. But....  
    
    I find middle management a bit difficult to motivate, too hard to dislodge
    from internal meetings and too removed from the customer world sales 
    people live in.
    
    I find our engineers attached to their facilities.  I think it is far
    easier to get all of the senior information technology  executives from
    my account to spend 3 days away from their family and office, to come
    up and spend some time with an engineer in Mass., then it is to get an
    engineer to spend a few days at my account. I think there is something
    wrong with that.
    
    I find sales support a bit defensive, too glued to hardware, somewhat
    timid about standing up and fighting for our technology.  I think
    sales support is too committee oriented, too slow to react.
    
    I think our corporate executives are untouchable. Why bother
    meeting if every word has to be prepared before the meeting.  Hmmm, why 
    is it easier for me to meet with the chairman of my 7 billion dollar account
    than it is for me to meet with a corporate VP of my own company!? I think 
    our execs are too difficult to involve in selling, yet I think they could 
    sell a great deal. 
    
    I think customer service is under rated, under compensated and too
    invisible.  I think these people have access to more selling
    opportunity then most sales people and they don't even know it.  I
    think customer service people can make a relationship with a customer
    work and can destroy it, yet they seem, for the most part, to operate
    totally independent of the sales person responsible for the
    relationship.  I think they need to sell too.
    
    I think we ALL NEED TO SELL TOO.  I think we are all in sales and to
    say that our sales people don't know how to sell or don't know how to
    sell what we make is untrue....and if you think it's true...really...
    then you should be embarrassed...you should go learn how to sell it!  
    
There, that was fun!  Inappropriate, but fun. :)

In MLBD (my life before DEC) I worked exclusively on IBM midrange systems.
And some of my best friends still work on them.  :^)  I can tell you that
we should not lose to AS/400's.  I absolutely believe that .28's experience
(no losses in the last 18 months) should be TYPICAL.

I am further very impressed by the rest of what .28 says.  It is pretty close 
to my experience in the field.  I have just a couple of comments:

>    I find middle management a bit difficult to motivate, too hard to dislodge
>    from internal meetings and too removed from the customer world sales 
>    people live in.

That's true in almost every part of DEC, not just the field.  That's my
experience, anyway.

>    I find our engineers attached to their facilities.  I think it is far
>    easier to get all of the senior information technology  executives from
>    my account to spend 3 days away from their family and office, to come
>    up and spend some time with an engineer in Mass., then it is to get an
>    engineer to spend a few days at my account. I think there is something
>    wrong with that.

In s/w engineering, I believe we are trying to change this mindset.  There
are many people who would like to have a lot more customer contact.  I 
believe this situation is much better than it was, say, 3 or 5 years ago.    

>    I find sales support a bit defensive, too glued to hardware, somewhat
>    timid about standing up and fighting for our technology.  I think
>    sales support is too committee oriented, too slow to react.

Interesting.  I found that sales support was untrained or inexperienced.
All my sales support experience suggests that they are VERY quick to react.
Finding someone KNOWLEDGEABLE to react was the hard part.

>    I think customer service is under rated, under compensated and too
>    invisible.  I think these people have access to more selling
>    opportunity then most sales people and they don't even know it.  I
>    think customer service people can make a relationship with a customer
>    work and can destroy it, yet they seem, for the most part, to operate
>    totally independent of the sales person responsible for the
>    relationship.  I think they need to sell too.

I think cust svc DOES know they have selling opportunities.  But it IS 
treated as an independent org and sales is generally completely unplugged
from the situation.    

>    I think we ALL NEED TO SELL TOO.  I think we are all in sales and to
>    say that our sales people don't know how to sell or don't know how to
>    sell what we make is untrue....and if you think it's true...really...
>    then you should be embarrassed...you should go learn how to sell it!  
    
At IBM, every single employee is expected to participate if an opportunity
to sell shows up.  Everyone is viewed as a "person who might make the 
difference" in customer relationships.  

We are certainly capable of that.  It just requires a focus we don't currently
have and a willingness to say "Yes" in ways we've not tried before.

Ken is right.  "Sell."  All of us.

K.

    
.28> I find our engineers attached to their facilities.  I think it is far
.28> easier to get all of the senior information technology  executives from
.28> my account to spend 3 days away from their family and office, to come
.28> up and spend some time with an engineer in Mass., then it is to get an
.28> engineer to spend a few days at my account. I think there is something
.28> wrong with that.

.29> In s/w engineering, I believe we are trying to change this mindset.  There
.29> are many people who would like to have a lot more customer contact.  I 
.29> believe this situation is much better than it was, say, 3 or 5 years ago.

    Unfortunately, my experience shows just the opposite. Three to five
    years ago, I was participating in field test situations where we
    visited customer sites, provided training on new features, answered
    questions and listened to concerns, and in general established engineering
    contact with key customers.
    
    Today, because of financial pressures, field test customers are brought
    to DEC and given field test training by non-engineering personnel. Oh, we
    were invited to have dinner with them one evening -- on our own time, at
    our own expense.
    
    I have a hard time equating this to a renewed interest in
    engineering/customer interaction.
    

	RE: Last couple. One of the real learning experiances I had working 
	DECWORLD was how painfully obvious it is that engineers *need* to
	spend more time talking to real customers. I believe that a lot of
	engineers would love to spend time with real customers. I don't believe
	management is against the idea in principal. However, there are other
	pressures on management. There is only so much time and money to get
	things done and the pressure is not to spend that time and money on
	getting engineers to customers. 

				Alfred

    re .28
    
    very appropriate and very accurate.

Re: .31

It would be interesting to postulate what successes DEC may have recorded had
we maintained a policy of getting our engineers and customers together on a
frequent basis. Instead of today saying "We cannot afford to do it" we might
instead be saying "We're glad we spent the bucks... look what we have reaped".

Lee

This "get the engineers to talk to the customers" attitude is
all very well (and I have no quibble with the reasons WHY you
think it's a good idea -- in principle, I agree) but on the other
hand, someone's got to write the stuff we're going to sell.

DEC is getting worse and worse and worse and worse about actually
delivering software in anything like a reasonable time frame.
And the software that's delivered seems less and less and less
likely to actually work.

My own (possibly prejudiced) explanation of this is that engineers
spend an ever-decreasing amount of time actually doing engineering.

Now, maybe spending time with a few customers can fix part of
the problem (in that we might manage to implement what the
customer actually needs) but I don't think it'll help either
the time-to-market or the delivered-quality problems.

So, if you want engineers to have time to spend talking to customers,
you'll have to somehow make a way for them to have that time
available.   And the one thing we cannot afford to give up
is time actually spent on product development.

I hope you won't regard this as an ivory-tower outlook; I'm concerned
with delivering the right product on time and with high quality.

Now, has MMS finished munging around with my sources?
Back to the debugging...    :-)

    Re .34:
    
    Please get into the METOO::QFD notesfile. You will find out a lot more
    about how it is essential for developers to spend the maximum time
    possible with customers, and also how to do it while optimizing your
    product development time.
    
    You can spend all the time coding you like, but if what you are
    producing is unsaleable, then you are wasting time and money.
    
    Too many times have I heard "OK, you guys start coding, I'll go out and
    get the requirements....."
    
    Ray

	RE: .34 In other words, let's keep moving, we'll decide on a destination
	later? I do agree that quality and time to market are very important. I
	spend my days "breaking" other peoples software so I have an idea of
	what quality is like around the company. But bug-less software that
	doesn't solve the customers need is not very useful. We have to stop
	setting this up as a complete zero sum game trading off quality, time
	to market, and meeting the customers needs as if they were seperate and
	only loosely related items.

			Alfred

    re. 35
    
    Which topic and notes in the conference?

    Re:34
    
    
    "It does not matter how fast we run if it is in the wrong direction".
    

    Well, before my reputation completely vanishes, I suppose
    I'd better enter a rebuttal to the rebuttals.
    
    I quite agree that customer input is essential when we're
    trying to decide what to build.  Furthermore, having DEC
    engineers talk directly to customers (I don't care where it's
    done) is a great way to get this input.  Not only does it
    help to ensure we build the right thing, but it does a 
    power of good for the way customers view DEC.
    
    However, it wasn't clear in the original note quite what the
    intention was.  I'm concerned that, after we've decided
    what we're going to build, that we actually let people
    get on and build it without too many interruptions.
    I assume in this that we made some fairly reasonable decisions 
    about what to build in the beginning.
    
    So, I read the original note as a request that engineers
    help out with "sales visits" at more or less any time.
    That might be good for the customer, and it might
    help get ongoing input as to what's needed in
    "the next version", but I persist in thinking it's
    not good for the software that's being developed.
    Writing good code requires enormous concentration.
    It's not something you can do part-time. 
    

    re:39
    
    Engineers need to spend more time with Customers because it is the
    most effective way to understand what product features are needed,
    and what the features are actually used for.  Some level of direct
    personal observation is indispensible to an Engineering group.
    
    Making a sales call is one helpful way to contact the Customer and
    gain understanding of their needs.  Another good process is to work
    with the CSC's handling inquries, problems, complaints, and
    suggestions.  Another good process is to participate in organizations
    such as DECUS.  All of these activities have the side effect of
    promoting sales.  
    
    Understanding the Customer's needs is as important as designing and
    testing a product.  Speed comes from knowing the relative importance
    of various product features to the Customer, and providing the most
    important/quickest ones first.
    
    Heads-down coding time is not the primary measure of a top-notch
    engineering group.  Building something Good, Fast, *and* Cheap! 
    Now that is top-notch engineering.  And it sells.

    
    
    
    re: .40
    
    
    	Good, fast and Cheap doesn't come unless your given the time to 
    	do it.
    
    	I agree with .39. Customer input is *essential* prior to starting
    	coding but once it's decided what the customers needs are give the 
    	guy the time to actually build what the customer wants, don't 
    	constantly pull him/her off the project or the product will never 
    	get built.
    
    	I don't mean to say engineering is untouchable once the project
    	is underway, but a happy medium needs to be met, like
    	tele-conferencing and exchanging mail directly with the customer
    	etc...
    
    							Mike
    							---- 

re: .39

I find myself agreeing with dave (well in a limited sort of way...no guar-
antees, expressed or implied :-). We far too often here at DEC (I guess 
elsewhere as well, it's just one of those human condition sort of things), 
over focus on one [or a few] piece[s] of a problem at the expense of the 
others. You know, this week it's SELL, next week it's whatever. The ten-
dency is to move (some would say leap) from one issue-of-the-day to the 
next. Somewhat like cycling from one affirmative action program to another
in an attempt to make up for perceived defficiencies. If we're not careful, 
the process becomes an end in itself and not a means to an end. 

My intent here is not to disparage anyone, any particular function or any 
particular issue. The fact is that it requires many very complex activities
to successfully deliver the right product, at the right price, at the right
time. I support more customer, engineer contact, so long as such activity
does not "rob Peter to pay Paul". As dave said, writing good code is "not
something you can do part-time".

We need to better understand what it is to deliver winning products. It,
at the very least, requires the right people, the right process, the right
product and, dare I say it, the right management to provide the direction 
and the glue to hold it all together. It's important to note that, even with
all the right ingredients, each product cycle places different require-
ments on success. I suspect that these differences are, to a great extent,
the result of the variability of the people involved. Each team member brings 
something different to a project. For example, one engineer may have extraor-
dinary coding skills and as a result may have more time to devote to cus-
tomer contact, while others may not. Creating the best mix of resources 
you can and taking advantage of the resources you have (paying particular 
attention to the people) is, I suspect, the optimal way to go. All of 
which, IMHO, places particular importance and responsibility on "the right 
management...". But, that's rathole of a different color...
                     
Dennis

    
    Re: couple earlier
    
    If I remember correctly, this kind of gathering customer feedback into
    next version of new product development/idea should fall into the
    responsibility of old CSSE function or even Product Management and feed
    into Phase Review Process.
    
    Unfortunately, Phase Review Process become another beaucratic process
    victim itself. CSSE don't have enough customer contact as Sales does,
    neither they have first hand product developement tech info as
    Engineering does, therefore, you get the picture !!!
    
    From field/Sales point of view, they need some heavy techie to enterain
    customer to give them warm feeling that we have 1st class engineer
    behind the curtain to bail them anytime if they marry to DEC.
    
    Just my .02
    Michael..

    Go back over the past 10 replies and ask "are we assuming that the only
    software development model is the waterfall/Phase Review Process model?"

    Engineers need to have more contact with their target customers _throughout_
    the development process, to avoid getting feedback which has been over-
    filtered by well-meaning people who either miss key technical details or
    who "reprioritize" the information based on personal or political
    expediency...

    (Gee, can you tell that I finally got my copy of "Decline & Fall of the
     American Programmer" from the library ?:-)

    
    
 >><<< Note 1929.44 by MAY21::PSMITH "Peter H. Smith,MLO5-5/E71,223-4663,ESB" >>>
 >>           -< Does requirements gathering stop when coding begins? >-
    
    
    	No it shouldn't stop, but a stake has to be driven into the ground 
    	sometime where the spec for the version currently in development is
    	frozen so that too much time is not given to the nice-to-have feature 
    	at the expense of the must-have feature.
    
    
    							Mike
    							----

    re:44
    
    Requirements gathering must not stop when coding begins.  Product
    feature requirements are subject to continuous changes because
    the Customers needs are continuously changing.  Control comes not
    from blocking changes, but from being able to respond to them.
    
    Customers buy at premium dollars when they believe that a product 
    meets their current needs, and the vendor will keep up with them as
    their needs change.

    
    
    re: .46
    
  >>                                                  Control comes not
  >>  from blocking changes, but from being able to respond to them.
    
    
    Can you explain this a bit more ?
    
    

    A computer, unlike any other machine ever invented, has the capability
    of being many different machines through programming.  I think without
    realizing it, users understand this and when they need a wordprocessor
    they invoke the executable that presents the wordprocessor abstraction.
    Instantly their PC is now a wordprocessor.  If they suddenly
    need a spreadsheet, presto, it's a spreadsheet.  The user is
    programming his or her PC or workstation dynamically because of minute
    to minute requirement changes.  It matters little if these functions
    are performed by a single executable image or separate images all
    talking to eachother via some messaging protocol.  For the most part
    the user could care less.   Like it or not, the computer is not like
    any other machine and the same rules don't apply.  It can be changed,
    and the user will want it to change, because it can.   And there is
    nothing wrong with this.  

    I know of two cases where an individual developer used NOTES to
    establish a quick turn-around communication medium for eliciting
    "customer" requirements and product deficiencies including bugs and
    fixes.  Both cases were internal developments, but should serve as a
    model for how well an engineer can work closely with customers.  Many
    of you probably know about SEDT and/or OUTLINE.  Both of these internal
    products were midnight projects which demonstrated faster turnaround on
    requirements modifications and bug-fixes than products done in straight
    time for real money.   I know that there are other factors too, but
    these examples need to be understood by those who define processes for
    customer-engineering interfaces.
    
    Dick

Disclaimer: I am not an engineer but I -can- recognize a locomotive when I see
one. Anyway, most of the following applies to documentation groups as well.

We all appear to agree that customer input is very valuable throughout the
development cycle. And we agree that it does no good to race off at high
speed if the direction is wrong.

But the view of engineering from my seat in ZK2 is that resources are simply
spread too thin. People's time and effort are committed to more than 100% of
capacity, and there is always something unforeseen popping up -- a meeting with
a cooperating vendor, a trade show in which DEC really ought to be represented,
or a customer meeting. People do not refuse to take on these new tasks -- they
have to be done -- but something has to give and it is usually either schedule
or quality.

And it is not the case that engineering is busy building what they feel like
building and ignoring customer input. They are not racing off in the wrong
direction. They are busy moving existing functions to new platforms and
generally maintaining the huge mass of code we've been building over the past
decade -- and believe me they are doing this based on input from our existing
customer base. In other words, engineering is running as fast as it can simply
to stay in place!

So when I hear someone say that we have to engineer things to be "good, fast
and cheap" I am reminded of a story. [Please excuse the following descent into
US-centrism.]

Jim Bouton was a big-league baseball pitcher. About to face a fearsome hitter,
he discussed strategy with the pitching coach. The coach said, "You need to
throw one fastball high and inside, then -- boom, boom, boom -- three fastballs
low on the outside corner." Bouton replied, "If I could do that, I wouldn't
need a pitching coach."

The question is, how do we go about improving things? Here's my cut at it. 

I believe we either need to increase software engineering resources across the
board (fat chance) or to abandon some efforts so that we can concentrate on
others. If we don't, we will fail across the board. Cutting resources across
the board (e.g., 10%-30% budget reduction for all groups) is absolutely the
worst thing we could do.

I also believe that you get more and better work out of people if they are
working at 80% of capacity, as opposed to 120%, because at 120% they are too
busy working hard to think about working smart(er). And there are no "midnight
projects" from people whose midnights are spent at their "real" jobs.

I don't know much about formal quality programs but it seems to me they are
basically approaches wherein you are taught to stop and think about things all
along the way -- to make sure that what you are doing still makes sense. No one
around here has time to stop and think anymore.

JP
    

    
    Re: .47
    
    >> Control comes not from blocking changes, but from being able to
    >> respond to them.
    
    >  Can you explain this a bit more?
    
    It's not my statement, but what that means to me is that we don't
    control the market and its needs.  Customers will choose whenever
    they like to tell us what the want without regard to where that may
    come in the development cycle.  With that in mind, the point is that
    we can't simply put up a wall once we begin development and ignore
    all new data.  We have to have, within the development process, a
    way to monitor that incoming data that includes a way for us to
    evaluate it and make an appropriate response to it.  An
    appropriate response for some data might be to take it under advisement
    for the future and for other data is to re-evaluate what we planned to
    in light of this new data.  You can't always predict what would be the
    best thing to do.
    
    Fire fight mode comes when the process is always the same i.e.
    something new comes up and we drop everything to figure out how to
    do that new thing too.  That is not what "responding" means.
    
    Steve
    
    
     

>But the view of engineering from my seat in ZK2 is that resources are simply
>spread too thin. People's time and effort are committed to more than 100% of
>capacity, and there is always something unforeseen popping up -- a meeting with
>a cooperating vendor, a trade show in which DEC really ought to be represented,
>or a customer meeting. People do not refuse to take on these new tasks -- they
>have to be done -- but something has to give and it is usually either schedule
>or quality.

I think you'll find this to be true of most engineering departments at Digital.
Unfortunately, I've seen lots of people try to solve it by throwing more
engineers at it, but the usual outcome is that the problem gets worse, not 
better.

From my days as an engineer at Digital, I found that much of my time was spent
doing counterproductive things.

For instance, reacting to a fire that says "Just patch it together now, and
we'll worry about it later".  Typically, there's no real intent to worry about
it later, but the patches can trigger so many other problems that you ultimately
spend more time fixing the fix and the fixes to that fix than you would have
spent just doing it right in the first place.  Many times by a factor of two
or three.

Or, spending a lot of time working through process, designed more to reduce the
possibility of human error, but which really just impedes progress on all fronts
while doing nothing to address the very problems they're in place for.  There are
times when the process is too much, and times when the process is not enough,
but instead of worrying about the appropriate amount of process, we implement
worst case process for all cases.

Or, time spent in service to management:  Pep rallies... I mean staff meetings,
re-orgs, fire drills.

Or, time spent context switching from disaster to disaster.  I get at least 
three new "Drop everything you're doing and get to this right away" top 
priorities a week.  If I could address these in a less preemptive fashion, I'd
spend less of my time spinning my wheels and shifting gears.

I know how much work I can get done in the work environment I'm given.  I know
that I can get lots more work done if you lock me in a room with a workstation,
case of Coca Cola, big bag of Fritos, sixpack of twinkies and a day old pizza,
and it's about four times what I could get done during working hours with normal
inputs and normal process in the same amount of time.  Either will be equal
quality work.

In fact, I've been able to get a month's worth of "daytime" work done in a
single intensive weekend.  How do I do it?  Well, I break all the rules, get
done what needs to be done, and present it to my management Monday morning as
a "take it or leave it" done deal.  Not necessarily appropriate, but sometimes
it's the only way I can get something done that needs to be done quickly.

Yes, I agree that engineers are running flat out, and I agree that engineering
is spread pretty thin.  It's just that I think most of engineering's time is
spent doing things that aren't what we'd think its primary job to be.

.52>In fact, I've been able to get a month's worth of "daytime" work done
.52>in a single intensive weekend.  How do I do it?  Well, I break all the
.52>rules, get done what needs to be done, and present it to my management
.52>Monday morning as a "take it or leave it" done deal.  Not necessarily
.52>appropriate, but sometimes it's the only way I can get something done
.52>that needs to be done quickly.

Sounds good to me. We need to rekindle this kind of spirit.

I had an enlightening conversation with an engineer-type just a few days
ago... the project they were assigned to was way behind schedule and
everybody was working 105-130%. They indicated that the code was being
nitpicked to death... too many spaces in the comments and similar trivial
rebuffs. 

I'm all for good working code but geesh!!

Lee

    re: .53 & code nitpicking...
    
    I trust the complaints were made properly, in accordance with policy,
    the appropriate number of copies, etc. etc...
    
    Perhaps such whiners deserve a taste of their own medicine.  (Of course
    if there were 1025 spaces between each word in a comment, perhaps
    there's some justification to the complaints.)
    

    re:47
    
    "Control comes not from blocking changes, but from being able to
    respond to them".
    
    The entire process of gathering product requirements, creating the
    product, and selling the product, is a feedback loop that converges
    on a "good" product that satisfies a need.  But product requirements
    always change over time, because Customer needs change over time. 
    Creating a product is a matter of reaching a moving target.
    
    For the feedback loop to be stable, the development process must 
    respond to changes at a faster rate than changes can be presented
    from external sources.
    
    The primary rate of requirements change is determined by external
    factors (Customer business conditions) which cannot be influenced
    by the Vendor.  A secondary rate of change is caused by distortion
    in the Vendor organization, and this can be influenced by the Vendor.
    It is important to recognize the difference.
    
    Responding to change does not mean firefighting.  It means that there
    is a routine procedure for detecting the need for a change, evaulating
    it's value and cost, and selected an action in response.  And that 
    action is not automatically "Postponed for the next release".
    
    Response means there are multiple points in the development cycle where
    changes may be inserted, and this is expected in the development plan.
    It means that distortions of requirements are minimized by reducing
    the communication layers from Customer to Engineer.
    
    Good Engineering is a dynamic process that can track a Customer's every
    need even before the Customer may be fully aware of it.  And it sells
    at a premium all the time.

    Re: 53 and 54 (Code nitpicking)
    
    This is not good Quality Engineering, it is a pathological behavior
    that occurs when an organization loses focus on the understanding of
    what it's products are supposed to be doing.
    
    A proper attention to functionality, reliability, and performance,
    should leave no one with any great interest in code nitpicking.  We
    sell completed products, not code.

    It has proven at least to my product/group that not only is it
    important to get customer feedback during the days when you decide to
    build, but as you go along in development as well.
    
    Instead of having a fairly rigid set of field tests, we release a early
    baselevel or two to some of our field test cusomters so that they can
    tell us whether we are heading in the right direction or not.  And even
    after official field test starts, we distribute kits fairly often
    (about every 4 weeks).  By the time field test is over, we typically
    have given out 4-5 kits + patches.
    
    Most of our important field test sites are opart of the Internet and
    we distribute our field test kits via the Internet.  It's incredible
    how much time that really saves (especially for international sites).
    
    As an example, we totally redid our installation based on our field
    test customers advise and got a better product for it.  But we failed
    to pass our hard learned lessons to our "sister" product and they are
    going thorugh trial-by-fire just like we did.  Oppps.
    
    [Would you believe Dave Porter and I are in the same cost center?]

    
    In support, "firefighting" comes regularly. They key is to become
    involved in the development process before you support it. 

    
    Re .53:
    
    Was the engineering group in question going through a round of
    mandated Formal Inspections, by any chance?
    

Re: .56

It appears engineering, as well as many other parts of DEC(*) have made process
their goal rather than product.

Lee

(*) Insert the name of DEC or any big company of choice. It is a widespread
disease.

.59>Was the engineering group in question going through a round of
.59>mandated Formal Inspections, by any chance?

Based on my understanding, yes.

Excuse the continuation of the mild tangent, but:

It seems like whenever people get confused and overwhelmed, they tend to focus
on those things that they understand the best, even if those things have little
or nothing to do with the task at hand.

I have no problems with formal code inspections, given that they're done right,
simply because they can fall under the heading of "getting it right now so we
don't waste time fixing it later".

Then again, as long as the content of the comment is correct, or at least not
misleading, there's absolutely no reason in the world to be focusing on it.
Well, the reason is that you have time to kill, and are devoting it to making
an existing piece of code more maintainable.  Then, cosmetics are extremely
relevant.

If you're behind in your work, and you're doing a code review, concentrate on
the code, and if there's nothing you can find wrong, move on to the next module.

More to specific experiences:

I once worked on a product that did code reviews.  We spent lots of time talking
about indentation, capitalization, proper placement for constant definitions,
and general coding style.  I have no problems with doing this sort of thing,
because neatness and consistency are two of the (dozens) of things that
contribute to good, maintainable code.  The only problem was that in all those
code reviews, we totally overlooked the fact that the design sucked from the
ground up.

Before you do formal code inspections, it's important to get your priorities
straight.

    
    Re: formal inspections
    
    First, if the inspection time was spent "nitpicking", then the group
    using the inspection process did not understand it very well.  The
    process specifically suggests that an inspection team define what they
    consider to be "nits" and agree on an expeditious way of handling them
    so that they don't slow the process down from focusing on what is
    important.  In my experience, teams have agreed that inspectors will
    mark "nits" on their copy of the document and pass it later to the
    author without taking time in the inspection.
    
    Second, no process which is intended to help will provide that help if
    you don't understand how it works and use it that way.
    
    Formal inspections, "done right" as mentioned, can save you lots of
    time and money later on. 
    
    Steve
    

    
    What sells products is:
    
          (1)  Functionality
          (2)  Reliability
          (3)  Performance
    
    - in exactly that order.  "Cost" is a wild card feature that may
    precede or follow that list depending on whether the product is
    for a leading-edge market or commondity market.
    
    Code reviews have no effect whatever on product functionality, and very
    little effect on either reliability or performance.  "Maintainable"
    code does not sell, and it is a long way down on the list of factors
    that do affect a sale.
    
    Design reviews may have some effect on product functionality, and often
    have major effects on both reliability and performance.
    
    Customer feedback during design, development, and beta test may have
    significant effects on functionality.  Any Customer contact has a
    direct impact on future product sales, as well.
    
    So where is the bulk of our time being spent?

                  <<< Note 1929.64 by RIPPLE::PETTIGREW_MI >>>
                            -< Products that sell >-

>    Code reviews have no effect whatever on product functionality, and very
>    little effect on either reliability or performance.  "Maintainable"
                             ^^^^^^^^^^^                   ^^^^^^^^^^^^
And I would propose that maintainable code is more reliable because it is 
easier for the maintainer to see what is going on and where to make changes.  
Thorough testing is important, but maintainable code is NOT unimportant with 
respect to reliability.

>    Code reviews have no effect whatever on product functionality, and very
>    little effect on either reliability or performance.  "Maintainable"
                                            ^^^^^^^^^^^
I once participated in a code review for some code to display data in 
realtime.  There was a section of code that went something like:

	istatus = call sys$qiow(,,iosb,,)
	if (iosb .eq. error_1) then
		blah
	elseif (iosb .eq. error_2) then
		blah
	elseif (iosb .eq. error_3) then
		blah
		...
	elseif (iosb .eq. error_9) then
		blah
	else
		do successful completion stuff
	endif

Now, I contended that this code performed best when there were lots of error 
conditions expected, but was lousy in "normal" conditions.  Invert the logic, 
test for successful completion, else check for errors.  The way it was 
written, every successful QIO resulted in 9 needless checks.

BTW, I was told this was a philosophical difference and it would not be 
changed.  So much for egoless programming.

    
    Re: .64
    
    First I need to clarify.  Are code reviews an informal walk through the
    code or are you using this term to mean formal inspections which are a
    very different thing.
    
    If so, I want to challenge you a bit.
    
    You may be correct, but I suspect that .64 is your opinion based on
    anecdotal evidence.  What data is there to support your position?
    
    The reason that I'm pushing back is that there is documented evidence
    to suggest that you're not correct about formal inspections.
    
    Steve
    

Maintainable code may not sell, but neither does broken code.  If something's
broken and unmaintainable, you've got a real problem.

Once a piece of software has passed the unmaintainable event horizon, you have
three choices as to what to do with it:

1) Leave it the way it is, forever.  Not an option if you ever want V2 to be a
reality.
2) Make it worse.  Actually, people are trying to make it better, but usually
they end up harming both the design and maintainability in the process.  Each
subsequent "fix" or "enhancement" increases the difficulty of making the next
one, and it's done along an exponential curve.
3) Throw it away and start over.

There's no good reason to compromise maintainability on anything that you plan
on selling.

As for code reviews:  Well, if all you're looking at is comments and the number
of spaces between the function name and open paren, then you're wasting 
everyone's time.

On the other hand, it's a pretty magical piece of software that has no bugs
that are bugs of implementation rather than bugs of design.  Design reviews
find the latter sort of bugs, but code reviews find the former.  In any given
software module, there will be loads of bugs of implementation.

Finding implementation bugs in a code review before you ship is much faster and
cheaper than shipping the code, getting bug reports, debugging, and shipping a
maintenance version.  I have never seen a proper code review not pay for itself
in time saved in this way.

Of course, I've seen precious few proper code reviews, as most seem to rathole
on counting spaces and casification.

	Re: .60, it started me thinking

.60� It appears engineering, as well as many other parts of DEC(*) have made 
.60� process their goal rather than product.

	Forgive me, I can talk forever about this! ... (and by the time you
	are through, you'll think that I have ...:-)!

	My 'take' is from a Software Engineering perspective ....

	"Product" is still the ultimate goal.  I don't think that companies
	have lost this focus.  What has happened is that most have come to
	realize how important the process of producing the product has truly
	become with respect to quality/profitablility.  Think of it as 
	efficiency.

	If you are not taking an active role in this effort, then there is
	a strong chance you misunderstand the reason for all this activity
	which seems to surround you.


	A good process begets a good product.  The process defines the
	necessary steps one must take to acheive the goal of making a 
	product.

	A product built without a process, regardless of how "good," (you
	can define "goodness"), cannot be enhanced or duplicated, except at
	tremendous cost and effort.

	Why?  Because no one knows how to do it -- they don't know the
	'process,' or, more specifically, how 'it' was done the first time.


	Permit me, if you will, to provide a couple of other ways of looking
	at it --- 

	A good product without a process is not a 'product' at all.  Rather,
	it is a one-time "artistic" acheivement.  It's sort of like saying:

         "Hey, you know, this 'Mona Lisa' is great!  Let's make some more!"

	But it hasn't been done yet (I'm leaving room for the possibility ;-).  

	The "Mona Lisa" is "art," not a product.


	What if you look at the root word, PRODUCT, in these statements?

          A PRODUCT is an entity which is PRODUCED following a defined
          series of steps.  (Each step is a PROCEDURE; the sequence of
          steps is the PROCESS.)

	  Selling the PRODUCT PRODUCES revenue.  To continue generating
	  revenue, the PRODUCT must be rePRODUCed.  But rePRODUCTion
          depends upon knowing the steps which were necessary to build
	  the PRODUCT in the first place!

	We've come full circle, "If we don't know how we did it, how can
	we redo it?"

	As I use the word 'reproduction,' I do not mean making copies. I
	mean subsequent versions.  

	Why the focus on Process?
	
	Unfortunately, we keep on forgetting how we 'climbed the mountain.'
	We haven't defined (or, at least, recorded) the 'HOW' of how we 
	got to the top.  Worse yet, we are not passing this critical know-
	ledge on to those who follow.  Result:  we "reinvent" instead of
	"reuse."  What is that, 'artistic license?' .. ;-)!

	It is through defined processes that we attack and solve these
	problems.


	There are risks.  

	Assume a doctor is performing surgery.  Obviously, the goal is to heal
	the patient.  The operation is performed meticulously - in classic
	style, but the patient dies.  The doctor paid too much attention to
	the surgery, itself, and missed signs which would indicated the 
	patient was in trouble.

	Similarly, if an organization is truly focused only on process, then
	they, too, are off track and may have lost sight of the real goal.  A
	process can be 'perfect,' but what good is it if it doesn't solve the
	problem?  The process we define must help us acheive our goal.  
	Whenever conditions change, the process must be changed as well.  


	The bottom-line is that process definition is only the first step a
	company makes.  A company does not and cannot operate in a vacuum --
	that is not reality.  To live in that world, its processes must be
	dynamic as well.  Afterall, having learned to breathe doesn't mean 
	you can now stop breathing just because you 'know how' .. ;-)!  

	I appreciate the chance to share my ideas on that "dirty-word" -- 
	process.

		Ron

    re .67
    
    Any particular program in mind when you're talking
    about unmaintainability? 
    
    :-)

  I've had both bad experiences and good ones with code reviews. One
particularly bad experience was an informal review in which the author wasn't
allowed to be present. A group got together to review my code and after the
review they were all walking around with long faces talking about the "problems
in my code". 

  I was expecting something like the "if" statement in .65 but boy was I
surprised. To give you an idea of where their minds were at here's a sample. 

  You know how comment fields are suppose to start:

!+
!
!  Blah blah blah blah 
!  Blah blah blah blah 

  Well if you thought that, are you ever out of touch. They are suppose to
start:

!++
!
!  Blah blah blah blah 
!  Blah blah blah blah 

  If you don't have that extra "+" at the start of the comment field the poor
saps who follow will be hopelessly confused. Or more likely I ran into some
code reviewers who were hopelessly confused. All of the "problems" that drew
those long faces were of the same ilk. 

  But I've also been to code reviews that were much better. The best
combination seems to be an informal review with the programmer and about 3
others present where one of the other programmers reads the code out loud and
leads the review. 

  Anyone can make a mistake like the one in .65 and it's always good to get
them out of your program.

  George

    when i was in EDS, i was shipped to a training camp for 2.5 months,
    (every new college hire get shipped to that boot camp for grooming
    and screening).
    
    we write tonnes of code in COBOL and ALC, they grade it , if grades 
    always no good, you'r out'a of here, yes, fired !, no good, they said.
    
    i used to lose stupied points because i did not have the correct 
    number of blank lines between the flower boxes and kept miscounting 
    an extra blank between the if and the boolean expression after it.
    
    i must have had not too many missing blanks, i survived those 2.5 months
    code reviews and kept my job. few other in my training class could not
    count blanks as well, and they were terminated.
    
    /Nasser

    RE: .71
    
    Nasser, this adds new meaning to the phrase "fill in the missing
    blanks". Thanks, yet once again, you've made my day...
    
    Dennis

    re .70
    
    A good retort to the "!++" and "!--" crowd is to ask them
    to explain exactly what purpose those tags serve.
    
    (When I joined DEC in 1977, I read that the idea was to identify
     significant comments, so they could be automatically extracted
     in order to produce a sort of "logic manual" for the code.
     Well, I wrote such a program to learn Macro-11, didn't find it 
     very useful, and I've never seen *anyone* else ever use anything
     similar).
    
    I don't even like "!+" (or ";+", "/*++", etc).   In fact, a
    code review from me would tell you to take 'em out   :-) :-)
    

    As .73 rightly points out the !++ were to significant start and end of
    comments so that a logic manual could be prepared. (Using Runoff).
    
    Of course, now LSE can be used with it's Pseudocode support to fairly
    transparently do the same thing, and SCA can be used to analyze the
    source, and prepare docuemtnation on all of the components in the code
    (in a format, that can be fed straight to VAX Document), but too many
    engineer's can't be bothered with that.
    
    I have often argued that what Spitbrook (Hub of DEC SW Engineering)
    needs is a bit more awareness of, and use of the VAXset tools. I think
    that the investment in training on tools, would be paid back 100 fold
    in the improved quality of the end product.
    
    q

    >I have often argued that what Spitbrook (Hub of DEC SW Engineering)
    >needs is a bit more awareness of, and use of the VAXset tools. I
    >think that the investment in training on tools, would be paid back 100
    >fold in the improved quality of the end product.

    ok, but that is only one dimension of the equation of successful code.

    i.e the above might be considered a necessary but not sufficient
    condition for good software.

    a pretty code is nice, but it is like physical beauty, it is only skin
    deep.

    i tink we are getting off the base subject, so i'll shut up.                                             

        Re: .64

        You argue that maintainability is of no value to selling code,
        and should therefore not be important when implementing code. 
        But then you shoot your own argument:

>    Customer feedback during design, development, and beta test may have
>    significant effects on functionality.

        If you get good ideas from customers, how do they get into the
        code?  If your product is `maintainable', then it will likely be
        possible to add the customer suggestions without significant
        difficulty.  If the code isn't easily maintainable, adding the
        customer suggestions can often reduce the reliability of the code.

        Also, maintainable code is likely to be more reliable (an
        attribute you value) in both the first release and in later
        releases after changes have been made.  Creating maintainable
        code can also help you achieve good performance--write initial
        code that has the desired features and reliable (which you
        correctly identify as the top priorities) and then maintainable
        code makes it easier to implement any necessary performance
        enhancements.

        In summary, maintainability isn't a top feature to sell
        products, but it is important because it *enables* the creation
        of products that contain the features that sell products.

        					B.J.

    I had to beat "Nonstop" and we didn't have "FT" yet.  It was a FUnds
    transfer project at a 10Bil asset bank.
    
    I asked "my" customer, "what do we need to do to overcome this
    "nonstop" technology?  
    
    "Well, they are "expensive" and I'd actually need three machines from
    them.  Two on site (one just sitting incase the other fails) and the
    other 35 miles away for "daily backups" to an alternate electric grid.",
    he said.
    
    The application folks were with me, a small Mass. based 3rd party.
    I designed a system/network with one cpu local and the other 35 miles away,
    using trans lan bridges to create one lan, the software house wrote
    "remote logging" into their software (took about 20 days).  
    
    Customer got two machines...(low cost) and up to the last
    transaction failover (read minimum recovery time!)
    
    We won (900K)!, where traditionally, we would lose....
    
    The software house, based on this new capability went on to triple
    their sales over the next 6 months. (Which also incuded DEC HW Sales)
    
    A fine example of the value of software engineer/sales/customer calls. 

    Our products sell when:
    
       o  We listen to customers and understand their needs.
    
       o  We include appropriate features in our products, that will meet
          those customer needs.
    
       o  We tell the customer what we have to offer, and ask for their
          business.
    
    
    These are the critical areas where the Product Development Process
    needs improvement.  All other processes are secondary or tertiary
    influences without critical effect on the results.
    

    
    Re: .78
    
    I agreed with you totally until the following:
    
    > All other processes are secondary or tertiary influences
    > without critical effect on the results.
    
    Either these processess support the critical ones or there is no point
    in doing them.  If they support the critical ones and they are not of
    high quality then you still have significant risk that they might
    produce defects in the result.
    
    Steve
    

    Re:77, 79
    
    
    In *.77, Mark Ricciardi has given a fine example of how products sell,
    and what the most critical process steps are, for developing products
    that sell.  You will note that "code reviews" were not a prominent
    feature of the story.  The selection of technical features that would
    meet the Customer's needs was what determined the outcome.  The
    participation from a Software Engineering group, with direct contacts
    and understanding of the customer, the relatively quick response to
    the Customer's needs - These were (and are) the processes with primary
    influence.
    
    When there are many processes that influence the final result, we
    must pay the most attention to the primary dependencies.  When, and
    if those cease to be problem areas, we then move on to secondary and
    tertiary process improvement.

So, you're suggesting that those primary processes are good enough excuse
for writing garbage code that's unmaintainable?

Sounds like a wonderful way to push the secondary and tertiary processes up
onto the primary list.

As a matter of fact, wasting one's time fixing last year's software that
was poorly implemented (not poorly designed, but poorly implemented), just
because someone saw maintainability as a secondary or tertiary issue means
that we have a lot less time to devote to our primary issues, which is
getting the next piece of software put together.  In the mean time, while
we're not filling the next market demand (since we're trying to fix the
last one that we filled with a shoddy product), word is getting around that
we can't deliver on the product we said that we already had, because it
doesn't work.

Code reviews can take tons of "fix it later" time off your schedule, and
give it back to you so you can spend time working on the next great thing. 
Saying that maintainability is of secondary importance is the same as
asking for lifetime employment, fixing bugs on one product.

Then again, we do find ourselves doing a lot of that around here, so I
guess I can't argue with company policy.

.45>   	No it shouldn't stop, but a stake has to be driven into the ground 
.45>   	sometime where the spec for the version currently in development is
.45>   	frozen so that too much time is not given to the nice-to-have feature 
.45>   	at the expense of the must-have feature.
    
    This is exactly the kind of "waterfall" mentality I have refereed to
    somewhere in this conference (I think in this note :-).  The
    assumptions behind this statement are:

       1. Coding can't start until the design spec is "frozen"
       2. The design can't change after coding starts.
       3. Even if the project is headed in the wrong direction, it is
          not permissible to drop back to the "design" phase because
	  "we'd have to throw out the code" or "it takes too much
	  effort".

    In reality, when is the last time the final product looked anything
    like the frozen design spec?  When was the last time you saw a design
    spec at the end of phase0 which was detailed enough to code to?  When
    was the last time we developed a product with no changes from phase 0
    and the customer liked it [and the costomer was not the gov't :-)].

    I encourage every engineer at Digital to grab a copy of "The Decline of
    the American Programmer" or any other book which talks about software
    engineering.  The point is that we can't adapt and serve customers
    until we can first _describe_ the process we are using, and second
    _improve_ the process we are using.  Currently, the phase review
    process is broken, nobody follows it as written anyway, so there is no
    way to improve our processes because we don't even know what we did to
    succeed on a successful project or fail on an unsuccessful one.

    If a design spec is going to exist independently of the code, it needs
    to be updated to reflect the code on a constant basis; otherwise, it
    needs to be clearly marked as obsolete and then deleted...  The design
    spec also needs to be updated based on customer feedback.  That brings
    up another question -- when's the last time a customer _saw_ a design
    or functional spec?  Was the spec able to convey the functionality, or
    was it meaningless to the customer?  How often is the working code the
    first true experience the customer has of the concept?

    I think I like the idea of rapid prototyping...
     

    Regarding the value of code reviews, they're clearly useless if they're
    used for pedantic nitpicking.  However, as a reveiwee always assume that
    what hits you initially as pedantic nitpicking may indeed be good advice
    (I've been in all four positions on this one...).

    The purpose of the code review should be entirely to fulfill the primary
    purposes.  In other words, the code review should ensure customer
    satisfaction...  This means the reviewers should be capable of evaluating
    whether the code meets the customers requirements, and should also be aware
    of maintainability/quality issues.

    I've been holding off on a code review for two months now, because there's
    not much point to having it.  The producer of the requirements is not that
    familiar with C (might not catch my logic errors), and I haven't found any
    engineers who are ahead of me on understanding the implementation (that
    will be remedied soon, since other engineers are passing me by as I sit
    here with my face in notes :-).

    I'll have the code review when I know that it will address the code's
    ability to deliver the required functionality.  Meanwhile, I'm spiffing
    up the comments and "self-reviewing" the code, with the target audience
    in mind...

Re: *.81

>> So, you're suggesting that those primary processes are good enough excuse
>> for writing garbage code that's unmaintainable?

   Well..Yes!  As a matter of fact that is true.  There are a lot of 
   products made with UGLYCODE, which have marginal Performance, and 
   rather dubious Reliability.  But when they contain all of the 
   Functionality to meet essential Customer needs, they still will sell.
 
   (Did I hear someone mention MS-DOS or UNIX?)

>> Sounds like a wonderful way to push the secondary and tertiary processes up
>> onto the primary list.

   That is correct.  When you improve critical processes they move off the
   attention list, and the secondary and tertiary processes move up in
   ranking.  At some point, even code inspection may become the primary
   issue in selling software, but it should be way down on anybody's list
   right now.

>> Code reviews can take tons of "fix it later" time off your schedule...

   I believe that there is enough experience across the entire software
   industry to decisively refute this idea.  Code inspections are far
   more likely to occupy a development group in a futile clash of egos
   and aesthetic values while distracting the members from solving 
   issues of Functionality, Reliability or Performance.

   Only in environments where tests are extremely difficult to perform 
   or reproduce (like some  Real-time applications), does code inspection
   offer enough benefits to offset the time spent.
    
   In any event, the number one influence for selling software products
   is Functionality.  The processes for defining product features is 
   where the most process improvement should be focused.

I am reminded of the old story about the blind people experiencing an
elephant -- they each came up with a different viewpoint.

To understand and reconcile the various viewpoints, we need to step
back and take a systems viewpoint.  That means understanding the
interactions between the various aspects.

Let me give an example of an interaction:  .78 emphasizes three points,
the first being listen to customers, the second being include
appropriate features.

It's not fair to toss off this second bullet, as if the hard problem is
limited to knowing that it needs to be done.  What happens when the
result of doing the first is that an appropriate feature for the second
is reliability?  

If including appropriate features is a critical area, then the
processes that enable you to include the appropriate features is also
critical.  There are clearly customers and applications for which
reliability and longevity isn't very important; it's perfectly
acceptable in those cases to write throw away code that doesn't get
reviewed, or even tested heavily.  A more common situation is that
reliability and maintainability (which includes the ability to quickly
change the product to meet the customers new understanding of their
needs, after receiving the initial prototype version) are important
features.  If that's the case, then tactics such as formal inspections
are the tactics that enable you to meet this critical area, and thus
are critical parts of the process.

I like to emphasize meeting customer requirements as a criteria for
formal inspections.  True, a code inspection will most commonly turn up
problems related to coding and code reliability, but if they're done
right, they can uncover failures to meet customer requirements, at
which point they become tremendous wins.  Of course, ideally you'd like
to find these earlier, but you can't always.

   Gary

    Customer contact with Engineering, as part of the product feature
    definition process, will help sell.
    
    Customer particpation in the beta test process, with a rapid corrective
    feedback (e.g code/design/feature changes prior to release) will help
    sell.
    
    These two processes are the primary influencers and should be getting
    most of our attention and effort right now.

	The purpose of formally reviewing code is to verify that it implements
	the design (nit-picking is OK too if there is time).

	The purpose of formally reviewing a design document is the verify that it
	implements the functional specificaiton.

	The purpose of formally reviewing a functional specification is to
	verify that it implements the requirements document.
	
	The purpose of formally reviewing a requirements document is to verify
	that it reflects the market survey (what customers will expect of
	such a product by FRS).

	Therefore, the purpose of a code review is to verify that the code
	implements customer needs.

	if a = b, and b = c, a = c.

	These reviews must be costed in the project plan.
	If the market survey changes because new competing products arise,
	then all of the documents must be changed and the changes reviewed
	(no I wouldn't review the whole of every document, just the change).
	At the functional spec, the cost of the change can be estimated,
	quoted,and resources scheduled and allocated.

	Every s/w engineer in this company has 
	a copy of the Software Engineering
	Manual 1988 in their office; none has read it.  It was current in 1988;
	if they'd read it we could modify some aspects together and move on.	
	It is true we have undocumented processes.  The SEM was our big
	chance to have one 4 years ago.

	Tom

    Gee, I know of at least one project that is basically writing code
    directly from the architectural specification. Dangerous...
    
    q
    

    re: .87
    
    Any engineer who has a copy of the SEM can throw it away.  (No, somebody
    should send me one, since I've lost mine, and I like to keep silly
    stuff like that.)  It was declared obsolete over a year ago by SQM(?)
    and you can't order it anymore.
    
    Bob

    
    
 <<< Note 1929.82 by MAY21::PSMITH "Peter H. Smith,MLO5-5/E71,223-4663,ESB" >>>
             -< Forget phase review, and we _do_ need process... >-

.45>   	No it shouldn't stop, but a stake has to be driven into the ground 
.45>   	sometime where the spec for the version currently in development is
.45>   	frozen so that too much time is not given to the nice-to-have feature 
.45>   	at the expense of the must-have feature.
    
.82>    This is exactly the kind of "waterfall" mentality I have refereed to
.82>    somewhere in this conference (I think in this note :-).  The
.82>    assumptions behind this statement are:

.82>       1. Coding can't start until the design spec is "frozen"
.82>       2. The design can't change after coding starts.
.82>       3. Even if the project is headed in the wrong direction, it is
.82>          not permissible to drop back to the "design" phase because
.82>	      "we'd have to throw out the code" or "it takes too much
.82>	      effort".

    
    Your mistaken. That's not what I'm saying. I'm saying that once you've
    gone through the QFD process the customer/s have already told you what 
    you want. Your job is now to build it. 
    
    Points 2 and 3 should be answered by the end of the QFD.
    
    There are always certain parts of the product that you *know* will be
    in the next release so coding can start immediately and during the QFD 
    other wanted features will come to light rather quickly.
      
    Given only so many hours in a day and only so many engineers on the
    project. You need to say at some point in time I need to deliver this 
    product by such and such a date. Bells and whistles are nice but if the 
    heart of the product your building isn't working the bells and whistles 
    don't do a hell of a lot of good.
    
    							Mike
    							----

    Just because the existing process is cumbersome, doesn't mean that we
    should switch to working with absolutely no process. 
    
    The number of times in this corporation, I have seen group X do
    something that really should be in group Y's bailiwick, just because
    group Y hasn't. (And then not follow through with continuing support
    etc), frightens me.
    
    q
    

    
    Re: .84
    
   >> Code reviews can take tons of "fix it later" time off your schedule...

    > I believe that there is enough experience across the entire software
    > industry to decisively refute this idea. 
    
    I'd like to see a reference to that experience, because I don't think
    that it exists other than as anecdote.  All the data we have on formal
    inspections says that taking 'tons of "fix it later" time off your
    schedule...' is right on the money.  Formal Inspections are widely used
    in the industry.
    
    > Code inspections are far more likely to occupy a development group
    > in a futile clash of egos and aesthetic values while distracting
    > the members from solving issues of Functionality, Reliability or
    > Performance.
    
    Formal Inspections, done right, will NOT produce this situation.
    
    Steve
    

    
    	Process is nothing more than a set of tools. Used correctly they
    should quality to the given effort.  I have however, seen tools -
    particularly Phase Review Process for purposes counter to their
    original intent.  Like using a hammer in place of a saw - if you
    manage to cut thru the surface, you still leave a very jagged edge.
    
    	When a manager or consultant engineer or whoever has a bigger
    gun than yours dictates we will use hammers inplace of saws, they
    will use it on you first if you object.  It is these types of
    activities - perversion of intent that can still produce a horribly
    mis-configured product while claiming following the letter of the
    law that gives process a bad name.  
    
    	So, one must never make value judgements based on what tools were
    used, but only by the final product.   There are fine carpenters that
    can build marvelous furniture without using the finest table-saw. There
    are equally fine software developers who can do the same.  It takes
    more than just legistlative edicts to generate quality products. Use
    the tools that work well and are a means to an end, and not an end goal
    in themselves.
    
    	bob

>>> Code reviews can take tons of "fix it later" time off your schedule...

>   I believe that there is enough experience across the entire software
>   industry to decisively refute this idea.  Code inspections are far
>   more likely to occupy a development group in a futile clash of egos
>   and aesthetic values while distracting the members from solving 
>   issues of Functionality, Reliability or Performance.

Nice, but your assertion is clearly outside of 100% of the experience I've had
cleaning up after someone else's potty code.  As a matter of fact, I'm occupied
in a full time job in which I'm chartered to do nothing else but clean up
after someone else's potty code, and the clear majority of things I find wrong
are problems that could have been found in either a design review or 
implementation review.

Why am I occupied in this job?  Because the customers have been complaining 
about quality.  They've also been complaining about missing features, but
quality is clearly on the list.  If a tool doesn't do what it's supposed to
do, the complaints come rolling in.

We could rathole here on a conversation as to why I'm not also chartered to
address function, which is clearly important, but maybe that's not even a 
rathole.  Fact is that there isn't any good reason why I shouldn't be doing
both, other than the fact that I find myself occupied just about full time
putting out immediate fires (CLDs and the like), and any leftover time I have
is supposed to be spent working on the problems of only slightly less priority.
Ignoring those CLD and showstopper QARs would have a very noticeable effect
on our word of mouth advertising.

Now, of course, this is just anecdotal, but I've been anecdotally wasting my
time for years providing backup to all sorts of people who like to use that
"maintainability isn't important" excuse.  

>   Only in environments where tests are extremely difficult to perform 
>   or reproduce (like some  Real-time applications), does code inspection
>   offer enough benefits to offset the time spent.
 
Perhaps for a beginner programmer, but I find that for normal debugging, a two
or three minute glance at the sources finds the bug for me a lot faster than
I could setup a debug environment and invoke VAX Debug.  Code reviews just do
that on the front end, and with broader scope (not looking for a particular bug,
but any bug).  And code reviews also do that without all the process that goes
along with answering a CLD, SPR or QAR.

> Code inspections are far
>   more likely to occupy a development group in a futile clash of egos
>   and aesthetic values while distracting the members from solving 
>   issues of Functionality, Reliability or Performance.

The answer is simple:  Hire programmers instead of primadonnas.  If you find
that your time is wasted with ego clashes, then you've got problems that go
a lot deeper than whether or not you should be doing code reviews.  Avoiding
this problem by avoiding code reviews is just that: avoidance.  It doesn't
solve anything, but it does let the problem fester.

    
    Anecdotally speaking, 99.44% of all the real problems found through
    inspections would also be found by comprehensive testing.
    
    The other nice thing about testing is that (assuming you automated it)
    it's reusable. Inspections (at least until we start to comprehensively
    gather and interpret the results) are 100% throw-away work.
    
    If God wanted me to read code line by line -- she would have made me a
    compiler!  (Probably COBOL :-)
    

  Testing catches logic errors, but for performance it comes up a bit short.
For example, that program segment we saw a while ago that tested for the least
common thing 1st, the next least common thing 2nd, ... the most common thing
last, would work fine and all the tests would run, but it would be slower than
if it tested for things the other way around. That sort of thing can be caught
by a code review. 

  The other thing is readability. I'm working on a project now where we are
using sources from two groups. One set of sources reads like a novel. It's
clear, well commented, uses useful variable names, and is a joy to work with.
The other set is C code with no documentation, no comments and variable names
that are very cryptic. It is almost impossible to figure out what's going
on at any point or why.

  I agree that testing is important. You don't want to go through code reviews
every time you change a line of code. But for version 1, major rewrites, or for
cleanup after several years of maintenance, code reviews have their place. 

  George

Before you get around to doing "group code reviews", you can
find a whole lot of errors by reviewing your very own code.

This sounds elementary, but it seems to me that many programmers
don't actually go back and read their "working" code to see if it
really does what it's supposed to do.  I've never understood
this -- I usually find more problems by reading code than
by fooling around with debuggers, dumps, baling wire, and 
all that hooey.  Usually, it's the case that after you've
written all the code, you then understand the total setup
a whole lot better than you did when you started, and therefore
it's the right time to go back and check everything's ok.

--

Of course, there's probably as much chance of getting someone
to this as there is of getting him/her to actually check
over the content of a memo before mailing it out to the
world!

----

re .95

>If God wanted me to read code line by line -- she would have made me a
>    compiler!  (Probably COBOL :-)
    
Well, I suspect you were probably joking when you wrote this,
but: if God hadn't wanted you to read code, she'd have made
you work on an ASR33.

          <<< Note 1929.97 by MU::PORTER "Justified Ancient of Mu" >>>

>written all the code, you then understand the total setup
>a whole lot better than you did when you started, and therefore

And then there are times where you may still be completely baffled by some of 
the code.  I worked in an environment once, where mnemonics were limited to 6 
characters, some of the subroutine source code (binary to ASCII, etc.) had 
been lost and our "source" was the output of a disassembler, very few if any 
comments, labels such as GOON (which baffled me until I ran into the author 
one day and he explained it was GO ON) and so on.  You had to do your own 
memory management (4K application segments), core (yes, real core) dumps were 
accomplished by toggling in binary values at the console, code and system 
changes were by punched cards which were fed in after your original source was
read from tape, updated, written to a new source tape, then a new binary was
written to a third tape, then you went through a similar process to build a
new system tape, loaded the new system, and did your testing.  Given that
environment, I became quite accustomed to performing walkthroughs,
understanding (as much as possible) what the code was doing, and then
attempting to implement changes. 

Management had misunderstood the requirements, so we had two months to add a 
big piece of functionality to the code.  I worked 'round the clock, 7 days a
week, stopping only for vending machine meals and occassional sleep, for two
months.  Got the code finished on time, launched the bird, and then, 6 months
later, I was still discovering why certain things worked the way they did. 

Probably would have been a whole lot easier, saved me a lot of debug (some for
trial and error, to figure out what the code was doing), and ended up looking
better for the next person, had the previous hackers written maintainable
code.  I am happy to report that the code did turn out very reliable, and 
hopefully, the parts I touched were MUCH more maintainable.

    Once again, a note and discussion about marketing and selling and
    customers goes down a technical nit and/or internal process rat hole.......
    
    

	It may seem funny, but a lot of the disagreement around methods
	(such as formal inspections) and process (such as Phase Review)
	boils down to the basic concepts of freedom and discipline.

	Over and over in history we see a cycle something like this:

	1. Someone discovers a great way to do something (almost always
	   by personal experience, usually trial and error).

	2. It occurs either to that person, or more often someone else,
	   that others could benefit from this better way of doing things.
	   There is an attempt to write it down, codify it, turn it into
	   a method or a process.

	3. Then the fun starts. In varying degrees, others try to apply
	   the method or process to the work, and get the excellent results
	   the original craftsman obtained. There is a spectrum, from the
	   ideal case where the participants voluntarily agree to use the
	   method/process, to the worst case where it is imposed on them
	   unwillingly by authority, with sanctions.

	It seems plausible that the goodness of the results will vary with
	the willingness or "buy-in" from the participants. At least, that's
	what De Marco and Lister say in the chapter on "Methodologies" in
	their classic book "Peopleware". They argue that when the word is
	spelled with a lowercase "m", methodologies (or more usually
	methods) are like a craftsman's toolkit - he applies the appropriate
	tool in the appropriate situation, subject to his own judgment. That
	works. But when it is spelled with a capital "M", the methodology
	can become a wall of books containing explicit prescriptions for
	every contingency, seen by management as "the minimum" safety net
	to prevent lazy, foolish or irresponsible employees from screwing
	up. That is a recipe for failure.

	So really we're thinking about freedom. Nowadays, many people
	think of "discipline" as the opposite to freedom. But really,
	it isn't. In a sense, true self-discipline (the best kind) is a
	precondition for freedom. Thus, software engineers who are willingly
	using methods which they understand, trust, and control, are more free
	because they can do far better work.

	But over and over, methods and process become stale and dry. They
	begin to be observed only in the letter, not the spirit. This may
	be what happened with Phase Review in some quarters. And it would
	certainly prevent formal inspections from being effective.

	/Tom

>          <<< Note 1929.93 by TOOK::SCHUCHARD "Don't go away mad!" >>>
>               -< One can always make a mess regardless of tool >-

Red herring #1:

>    	When a manager or consultant engineer or whoever has a bigger
>    gun than yours dictates we will use hammers inplace of saws, they
>    will use it on you first if you object.  

Sure, SOME persons of authority will misuse that authority.
That is NOT the normal course of events.  
Yes, there are instances of edicts from "on high" that set technical
or procedural direction for a project that do not seem optimal 
for that project, but that might be (or are intended to be) optimal
on a larger scale.  [SOMEBODY had to be the first to shift from BLISS to C,
for example.]  That's why we HAVE mangers and consultant engineers.
    
Red herring #2:

>    	So, one must never make value judgements based on what tools were
>    used, but only by the final product.   

Only if you can identify the final product.
We don't do onesies.  (Well, we do and that's the problem - one thing
at a time, in a non-reproducible way.)
The OVERALL product is a product FAMILY that plays together and grows
in a predictable, progressive way

Red herring #3:

>   There are fine carpenters that
>    can build marvelous furniture without using the finest table-saw. There
>    are equally fine software developers who can do the same.  

Maybe so, but these people, both carpenters and developers, are VERY, VERY rare.
Their hand-crafted output takes longer to build, is less predictably
scheduled, and leaves no trace of how the work was done so that 
other "fine pieces" can be turned out in the same way.

>   It takes
>    more than just legistlative edicts to generate quality products. 

Yes, it takes TEAMWORK and the admission that one person's work is a 
component of another person's work, and that teamwork requires predictability
and grounds on which trustworthiness can be built.

- tom]

re .100

Spot on.

    I'm not sure if y'all want to get back on track here or not... At this
    point in the rathole, I'm not even sure this has been discussed (or
    not), but.... I think the topic use to be "selling DEC to everyone".
    
    If that be the subject.... I was watching the Today show and saw a
    commercial for DUPONT... They were pounding their creative chests over
    the fireproof firefighting suits they had designed/made... 
    
    What struck me about the commercial wasn't the suit (which is
    impressive, when seen through the commercial)... BUT what impressed me
    more was the fact that.... not everyone would buy one of these suits,
    SO why then does DUPONT put such adverts on the tube....???
    
    They just might be putting the add on TV to catch the eye of just ONE
    firefighter or fire chief or one city official (responsible for getting
    funds for such equipment).... OR Dupont may just be advertising this
    product to make DUPONT a household name.... to help sell other Dupont
    products...
    
    Why is it that firefighting suits are advertised on "regular" TV, but
    Digital computers are not.... Digital computers are advertised only on
    Public Broadcasting station "stuffed shirted programs that only a
    certain culteral subset of the world watches". Is Digital to good a
    product for common folk to own? 
    
    Think about it.... a fireproof suit, used by few, is reaching more
    people than a computer that can be used by vertually everyone in the
    world.... IF THEY KNEW ABOUT THE.....!!!!! WHO IS Digital anyway..??
    
    Bob G.
    

.97:

Amen.  I've used that technique for years.  Just about as good is writing in
one language (high level) and proof reading in another (generated machine code
from the listing).  Sounds pointlessly difficult, but it does serve two purposes:

	1. To make sure that you're really telling the machine what you thought
	   you were
	2. To eliminate your own familiarity with the code (which has the
	   potential to make you overlook things, or not pay as much attention)

    We must advertise solutions, not products.  We must talk about the
    activities of small-medium-large businesses and the problems that
    have to be solved to continue those activities.  Then we must 
    explain how the features of our products solve the Customer's 
    problems.

    Our considerable Engineering talents must be applied to real
    Customer problems rather than endless refinements of internal
    processes.
    
    From *.97 (MU::PORTER)

> Management had misunderstood the requirements, so we had two months to add a 
> big piece of functionality to the code.  I worked 'round the clock, 7 days a
> week, stopping only for vending machine meals and occasional sleep, for two
> months.  Got the code finished on time, launched the bird, and then, 6 months
> later, I was still discovering why certain things worked the way they did. 

    The greatest and most immediate effect we can have on sales is to
    re-establish contact between Engineering and Customers.  Indeed,
    how else could we correct a situation when "Management 
    misunderstands the requirements".

    The one internal process we do need to always pay attention to is
    our basic response cycle.  How quickly can we detect the need for
    a change?  How quickly can we decide on some meaningful action
    that will address the need for a change?  How quickly can we observe
    the results of an action and get feedback on its effectiveness?

    A faster response cycle does not mean fire-fighting.  It means
    planning feedback loops in every internal process, which have
    minimum distortion, and maximum speed.  We must be able to observe,
    understand, decide, act, and observe again - quickly.  This applies
    to testing, coding, design, requirements gathering, customer contacts,
    sales orders, and manufacturing processes.

    It will also help to always return phone calls or E-mails.

re .-1
    
>    From *.97 (MU::PORTER)
>
>> Management had misunderstood the requirements, so we had two months to add a 
>> big piece of functionality to the code.  I worked 'round the clock, 7 days a
>> week, stopping only for vending machine meals and occasional sleep, for two
>> months.  Got the code finished on time, launched the bird, and then, 6 months
>> later, I was still discovering why certain things worked the way they did. 

I wrote .97, but none of the text you quoted had anything to do with .97.

--

I agree with your comments about shortening the "response cycle".
The current development cycle is absurd.   Within NaC, we're trying
to figure out how to get release cycles down to 9-12 months (for
all except big "V1.0" projects).  That in itself would be a big step
in getting engineering closer to uderstanding customer needs, simply
by making the feedback loop a lot shorter.   Can it be done?  Don't
know.  Do we have to do it?  Yes.

    Re:Error in attribution
    
    
    I referred to a quote from *.98 (NEWVAX::SGRIFFIN) which I incorrectly
    attributed to *.97 (MU::PORTER).  I apologize for the error.
    
    
    -Mike Pettigrew

Well, at least you didn't call me "Dave Garrod".

Re .95:

>    <<< Note 1929.95 by CROW::KILGORE "...57 channels, and nothin' on..." >>>
...    
>    The other nice thing about testing is that (assuming you automated it)
>    it's reusable. Inspections (at least until we start to comprehensively
>    gather and interpret the results) are 100% throw-away work.

Nonsense.  An inspection is throw-away work if the participants are walking
around in a daze.

Done right, the inspectors finish with a much better understanding of the target
document.  That pays off in better maintainability and evolvability when one of
them has to work with it later.

Furthermore, those who are aware will remember the mistakes that were discovered
and be less likely to repeat them.

And the way I've seen things work in Digital, the inspectors will probably learn
how to behave in a meeting.

(I presume you're deliberately ignoring the improvement in reliability and
maintainability one gets).
				/AHM

    
    Gee, I hope I'm not deliberately ignoring anything...
    
    There are better and much less painful and expensive ways for people to
    better understand the target document. Formal inspection is part
    (part!) of a comprehensive system to gain control of a process through
    intensive statistical analysis. Unless we, as a corporation, implement
    the rest of that system, we're pumping a lot of person-hours into
    formal inspectiona and throwing away the important, second order results
    (inproving the process). The enormous expense of formal inspection
    cannot be justified by the paltry first order results (improving the
    document) that I have witnessed in three different engineering groups.
    
    But maybe that's because those engineering groups had a fairly good
    process to start with...
    

    
    Re: .1929
    
    > The enormous expense of formal inspection cannot be justified
    > by the paltry first order results (improving the document) that
    > I have witnessed in three different engineering groups.
    
    While I would agree that it is very important to go after the
    "second order results", I disagree that inspections can't be justified
    with only "first order results."  If you can add inspections to the
    testing program you already have in place and as a result significantly
    reduce the number of problems that get to customers, it shouldn't be
    long before your maintenance costs begin to be reduced by much more
    than the inspections are costing you.  
    
    Steve
    

    
    I would agree, if formal inspection found a sufficient number of problems
    that otherwise would get to customers. My experience does not indicate
    that this is true.
    

Re .112:

>    I would agree, if formal inspection found a sufficient number of problems
>    that otherwise would get to customers. My experience does not indicate
>    that this is true.

If anyone cared, they could analyze the data from your group's inspections and
my group's inspections, and see whether the statistics corresponded to our
respective expectations.  A fair fraction of my group's data should be available
in the Lou Cohen archives, because I know we flushed photocopies of our file
cabinet out to him at one point.
				/AHM