Conference 7.286::digital

I agree COMPLETELY with the views of the anonymous author in the base note.
Standards are necessary and can definitely help in programming efficiency,
but the way DEC STD 095 and 065 are being enforced is crazy.

A few months ago I worked for a different group.  During my time there, 
particularly in my last year there, I tried making a huge stink about
standards.  I talked to anyone who would listen.  I went as far up the
management chain as I dared.  I wrote memos, used ODP, and tried to get people 
to act.  In the end, nothing happened.

I ended up personally rewriting an entire application TWICE, just to conform
to DEC STD 065 naming conventions.  We're talking about more than month's worth 
of my time, and NO NEW FUNCTIONALITY was added to the application.  The entire
effort was just changing field names in the programs and databases.

On another project for the same group we held up development for weeks (approx.
4 programmers X several weeks) just to conform to DEC STD 095 conventions.  And
in the end, it turned out that some of the DEC STD 095 standards did not even 
work due to the layered products involved.  This was a complete waste of time,
and no additional value was added for the users/customers.  

In trying to get management to do something, this was the analogy I used:

You are one of 18 people who work at a golf course mowing the lawns.  Each of 
the 18 people are responsible for one green.
  The owner says:  "From now on, all mowers will mow their greens in a 
                    North/South pattern"
  (I say this is a good standard, because it makes the place look good)

  Then the owner says:  "When you mow the grass near a tree, do it in a 
                         circular pattern around the tree"
  (I say this is another ok standard)  

  Now they owner says: "When you start your mowers you must place your left
                        hand on your head."
                       "When you put gas in the mower you must first place a 
                        clothes pin on your nose"
                       "When you drive in to work you must drive a blue car"

  I say these are analogous to DEC STD 065 and 095.  Standards carried 
  too far.  So far in fact, that you never get a chance to mow the lawn.

Vin

    
    Re: .0
    
    There is not enough information given about the standard to be able to
    answer your question about cost.  For example, are details of this
    standard things we should have been doing all along?   Will not doing
    it cost us even more in the long run?  Can you shed some more light
    on this.
    
    Steve
    

    What these standards/methods represent is the framework around which
    you build quality and consistencey. They are not an end unto
    themselves.
    
    The necessary catalyst is the willingness to do it.
    
    Gregg

With reference to the anonymous submission, and in addition to that submission:

European engineering subsidiaries were asked for feedback regarding DEC-Std-095.

We submitted a large amount of feedback.   Much of it relating to major concerns
around the incompatibility of this standard to our existing applications and
the way the Business in Europe handles it's software.  


All of this feedback was apparently ignored.   The version of DEC-Std-095 that
was released was identical to the version that was submitted for feedback.


With people in the process of being "rightsized" and groups vanishing in the
cuts, it is proving very difficult to have our concerns heard.   NOONE seems 
to "OWN" this standard.  All our contacts seem to have left or now have other
jobs, and DEC-Std-095 seems to have been one of the casualties.


DEC-Std-095 was apparently based on the USIM&T US Application Environment 
Standard.  Many of the requirements can be traced directly back to that 
standard and echo it word for word.    This standard was developed for the
US Engineering market, and may be perfect for the US way of implementing
their applications.  I will say, it's not all bad and that many of the 
requirements of this standard are useful and sensible, but for an European 
market, not *ALL* of them


As an example.  The European business prefers to install the new version of
appliction software in advance of the change over date, and migrating from the
old to the new when they are satisfied with the new version.  This is often
a period of weeks, especially if the release is relatively new.

Under the European Application Environment, this is possible to do on a 
single machine/cluster. Under the requirements of DEC-Std-095 this is not 
possible.    

Due to the requirements that under DEC-Std-095 the top directory of an 
application and the logical name table may *NOT* contain the version number 
[fac] and  fac$LOGICAL_NAMES   means that only one version of an application 
may be installed on a system environment at any one time.


This has expensive consequences.   Either the subsidiaries have to invest in
more hardware (in these days of cost-cutting),  or they have to install and 
migrate to new software in a *VERY* short window, both solutions are costly.


We have asked for approval for two very small changes to the standard to make
life for our Customers bearable -  [fac999] and fac999$LOGICAL_NAMES  not 
much to ask for (everything else we can live with), you may think.

...BUT WHO DO YOU ASK ? who is authorized to give approval ?   we can provide
 $n00,000 worth of justification for the change.


It may be that the US software engineering groups have the luxury of being able
to Field Test their products for long periods of time to prove their software,
but in the field of business software where there are very short developing 
windows and even shorter release windows, the best we can hope for is a couple
of weeks of "hand-holding" pilot.

We are very concerned with quality, and do our best to achieve this; but we
are also aware that with time squeezed from all angles, it is a next to 
impossible job to produce truely quality, problem free, software under todays
engineering conditions; thus it makes sense to enable the field to choose to
go for parallel running of concurrent released of software, if they feel that
this will reduce the business risk; and there is a risk entailed in every
release.


I share the concerns of the anonymous noter about a standard being imposed 
on existing software.  I totally agree that all new software, including new
additions to existing software be affected by a current standard,  but 
retrograde fitting ?   is this really sensible ?   is it cost-effective ?


 

    
    I recall over a year ago seeing a proposal for standard that was being
    pushed by (I've forgotten the name of the group) the internal
    information systems group.  It sounds like this might be one and the
    same standard that I saw.  I don't remember the details but remember
    having concerns with some of them.  My understanding was that this
    standard was to refer to software that was intended to be installed on
    DEC internal systems and was not intended as a development standard
    for software we were building for sale.
    
    Can anyone shed more light?
    
    Steve
    

Re: .5


Yes, that's the one.

re .4

>With people in the process of being "rightsized" and groups vanishing in the
>cuts, it is proving very difficult to have our concerns heard.   NOONE seems 
>to "OWN" this standard.  All our contacts seem to have left or now have other
>jobs, and DEC-Std-095 seems to have been one of the casualties.

If no one is in charge, then a frontal challenge is all that will be
effective.  Those who know there is a serious business problem should
prepare a white paper declaring their concerns and expressing their
conscientious decision to violate the standard in lieu of finding a
responsible manager.  Then forward it up though the command chain until
someone gives back an official answer.  If that answer is unacceptable, jump
that position and keep on escalating.  It's a long and lonely road, but I
can't think of anything else to do.

Good luck,

Dick

pd

   For the enlightenment of the originators of DEC-Std-095, consistency is
   not the be-all-end-all of quality.  Satisfying customer requirements is.
   

    
    Re: .9
    
    You give as a reason for not incorporating some of the feedback you
    recieved:
    
        BECAUSE I WOULD HAVE FELT OBLIGATED TO GO THROUGH THE GENERAL
        REVIEW AGAIN.
    
    What kind of a reason is this? What is the point of having a review if
    you do not take notice of feedback because it would mean having to go
    through the review procedure again.
    
    If I as a developer recieve feedback about problems in my code would
    the sender feel satisfied if I said "I am not going to take any action
    because it would mean the application would have to go through QA
    acceptance again"? *NO*
    
        THE AUTHOR OF THIS REPLY WAS NOT A PARTICIPANT IN THE DEC STD
        GENERAL REVIEW, WHICH WAS OPEN TO ALL OF DIGITAL AND WELL
        PUBLICIZED BY SQM AND THE IM&T MC.
    
    Well publicized??? The first I heard about it was ~October 1991. Which
    is apparently after all decisions had been made. How was it *WELL*
    publicized.? I feel that if Jane Alford had heard about the Genral
    Review she would have participated. It was also very convenient to
    forget her questions twice. Maybe because the questions were a little
    too searching or maybe I'm being too cynnical.
    
        THE PARTICIPATION IN THE OFFICIAL DEC STD GENERAL REVIEW PROCESS
        SPEAKS FOR ITSELF WITH OVER 90 PARTICIPATING INDIVIDUALS FROM ALL
        3 GEOGRAPHIES AND 34 WRITTEN RESPONSES.
    
    I don't believe it does. For an organization the size of DIGITAL the
    numbers mentioned are infinitesimal. Even if you take into account only
    those employees of Project Leader status and above.
          
    Chris.

re: .9,

> MY RESPONSE TO THIS NOTE AND ITS RESPONSES WILL BE IN BARBARIC
> UPPER-CASE ONLY TO ALLOW ME TO INTERSPERSE MY ANSWERS WITH THE ORIGINAL
> COMMENTS.

    	Speaking of standards, the standard means of replying to notes
    is to highlight the note text being responded to with greater than
    signs (as above).  Anyone here will tell you that upper case is used
    primarily for yelling and screaming.

    				    -davo

p.s.	On the other hand, I won't force you to reenter a standardized
    	version of your note.  ;^)

davo - that perfectly sums up the entire issue, except you'd have to
       make re-entering the note mandatory.

Vin

Re: .9

Thankyou for that reply John, and the time you obviously took to enter it.  
It has given me, and I hope many others, much needed answers.

    
>        THE AUTHOR OF THIS REPLY WAS NOT A PARTICIPANT IN THE DEC STD
>        GENERAL REVIEW, WHICH WAS OPEN TO ALL OF DIGITAL AND WELL
>        PUBLICIZED BY SQM AND THE IM&T MC.
    
No, I wasn't an individual participant because it was decided to select a
representative from our site who would attend that review and put forward our
collective concerns.  The person selected was Ian Preece, who did attend.

My involvement in starting to try to obtain clarification on some points was
because I was working on the task of updating the European Application 
Environment (APPENV) to conform to DEC Std 095, and thus had a very real 
interest in obtaining an in-depth understanding of the Standard and trying to
do the job properly, as it is this Environment that dictates the shape and 
Standard conformance of all our applications released around all the
subsidiaries of Europe. 

Your point on the FACvvv not being documented in the IS Acceptance Standard is
noted.  Maybe you should have had access to the supporting document the 
Application Standard User Guide, in which the directory structure and 
conformation is well documented...but then it's too late now.

    
Re: .10

>    I don't believe it does. For an organization the size of DIGITAL the
>    numbers mentioned are infinitesimal. Even if you take into account only
>    those employees of Project Leader status and above.
          

It would have been impracticable to send all interested parties to this review.
(Indeed there were many hundreds of us).  Representatives from each engineering
site, at least from here in the UK, were sent to the review with a long list.

I apologise for my earlier outburst of anger, it may have clouded my point,
which was that to migrate applications, in the current economic climate, from
one standard to another without justification (cost or otherwise) does not make
sense. Maybe they did justify it? Perhaps this is a restructuring excercise with
pay back over the next 'n' years? Who can tell us?

/Dave.

********* My opinion, not my Manager's, my group's or anyone else's *********

>Not only that, all this really addresses is environment, not an area we in 
>Europe have major problems in at the moment. We *do* (all of us) have a
>problem with software quality, quite another issue, and this standard won't
>make any major impact on that, at all. At least, that is, from a European 
>perspective.

Without wishing to take anything away from the rest of Laurie's note, the above
paragraph is the most important in my opinion.

A standard should be a means, not an end. ensuring that a product conforms with
a standard only proves that it conforms with that standard, it has no bearing on
the quality or appropriateness(sp?) of that software.

Any quality system should take into account the needs of the business, and the
restrictions of the customer requirements/budget. The result of the rigidity and
occasionaly inappropriateness of this standard, is that many decisions not to
retro-fit it to existing products will be taken. This is a pity, since many of
those products could have done with some improvment. Had the standard been
closer to current practices and more compatiable with other similar documents,
then perhaps it would have been applied to all our products.

We need to spend our money, our time and our people on getting the finished
product right, not on a standard which adds nothing to this finished product. At
a time when money is short, it seems strange that we are investing this much
resource into something that in many areas is deficient.

The issue, in my opinion, is much wider than DEC Std 095, which at least had the
right intentions behind it, and in a lot of cases has some good ideas. I believe
that we (Digital) have a tendency to pay lip service to quality. We are
concerned with showing all the quality standards and procedures and whatever
else we are writing and installing and with talking about how much we believe in
quality. We should be concerned with actually achieving quality, not documenting
it for the sake of it.

It is basically a very simple ideal and a very simple thing to achieve. It seems
to be giving us a lot of trouble even working out how to achieve it never mind
starting to. 

UK DSE is now working on what we believe will be a system which will help us to
achieve that end. To do so, we are talking to and working with people who
actually do that work, not their manager or supervisor or person responsible for
quality, but actually to the sharp end. But it will apply to us, because it fits
what we are doing and the way we do it. It should not conflict with what we
already do, it should add to it. I have high hopes that it will have a marked
effect on the quality of the work done by this group and it's various centres.
It would be inappropriate, however, to assume that it can be applied to all
other organisations blindly, it may form a basis for other similar systems
within such organisations, it may not, but it can't just be applied.

Unless a quality standard or procedure makes sense to the person using it, is
easy to understand and follow, then it will eventually fall by the wayside
having had virtually no effect. All standards and procedures should be easily
understood, simply followed, workable and appropriate. They should be maintained
in this state always. Problems should be fixed immediately otherwise money is
wasted following the wrong route and then coming back. They MUST be popular at
the sharp end. If people believe in your standards, then you just solved 75% of
your problem.

End of sermon.

M.

    Will someone send me the official communication that states that
    DEC Standard 095 should be implemented retrospectively in Europe.
    
    I find this suprising, as I was present at the European IM&T Policy
    board that specifically decided that NO RETOSPECTIVE action should
    be taken for Legacy applications within Europe on the basis of cost.
    That is to say the board correctly identified the exact concerns you
    are now raising and took the correct and appropriate action.
    
    Only new applications and those under revision would be considered.
    
    If there is any communication to the contrary it is incorrect and I
    will personally clarify the situation.
    
    If there is no formal basis for this discussion then I need to
    understand why we are wasting our time debating it.
    
    Chris.
    
    IM&T
    European Systems 
    Compliance Consultant

                                     

>    Only new applications and those under revision would be considered.

Does "under revision" include those applications for which any alteration to
functionality is to take place ? To explain, If I have an application which has
not been altered to DEC Std 095 level, and then the users request some
additional functionality, do I then have to apply the whole of DEC Std 095
before I may revise the product in accordance with the user's wishes ?

What does "considered" mean in this context ?

>    If there is no formal basis for this discussion then I need to
>    understand why we are wasting our time debating it.

We are not wasting our time. You have already stated one piece of information of
which I was not aware, more may become apparant. If nothing else, listening to
other people's feelings about quality and DEC Std 095 adds to my understanding
of the issues involved.

M.
                                     

re .18

>>    Only new applications and those under revision would be considered.

>Does "under revision" include those applications for which any alteration to
>functionality is to take place ? To explain, If I have an application which has
>not been altered to DEC Std 095 level, and then the users request some
>additional functionality, do I then have to apply the whole of DEC Std 095
>before I may revise the product in accordance with the user's wishes ?

>What does "considered" mean in this context ?

   I read "considered" as a requirement for an application by application
   decision process which may or may not result in a given existing
   application being brought into conformance with STD095 when it is
   revised.  This is obviously not an official interpretation, just one
   man's opinion of what seems like common sense.
   
   Let's keep our minds clear as we continue to examine the facts and the
   issues.
   
fwiw,

Dick

    Now lets calm down a bit please. I am trying to help here in three ways
    
    1. If you have a different view of what the DEC standard 095
       implementation is from what I know to be reality I need to help
       correct that.
    
    2. If 1) is true I need to know how that came about so I can
       investigate why this is, so I can improve the communication process
       so it doesn't happen again. Mis/non communication is one of the
       largest time wasters in DEC.
    
    3. If there are communications which state anything different I need to
       have sight of them also so I can again correct any
       misunderstandings.
    
    
    As to the discusion on the word considered, let me try and clarify
    that:-
    
    Consider the different status applications could be in:-
    
    
    1. New and not implemented           --  	DEC Standard 95 applies 
    
    2. Old and to be retired (legacy)    --     DEC Standard 95 does not apply
    
    3. In developement or functional rev -- 	Business justification as
    					        why DEC 095 is not
    					        appropriate ( cost,etc)
    					
    				                Otherwise it applies.
    
    			
    Standards are not absolutes. They are reference points from which
    discussions about justifiable deviations can begin.
    
    
    
    Chris...
    
    PS. By the way I don't own Dec Standard 095, If you wish to take up
    	discussions on its content,history and relevance you should contact
    	John Harrison @FYO of Release management.. He is you European Rep
        and as such owns this on behalf of Europe.
                                        
    

>    Now lets calm down a bit please. I am trying to help here in three ways

Ummm, I am calm. Are you reading something into what I said ? If I wasn't clear,
then I apologise. I am not upset, I am merely trying to get a handle on what is
being said.

>    1. New and not implemented           --  	DEC Standard 95 applies 

Ok.
    
>    2. Old and to be retired (legacy)    --     DEC Standard 95 does not apply

Ok

>    3. In developement or functional rev -- 	Business justification as
>    					        why DEC 095 is not
>    					        appropriate ( cost,etc)
>    					
>    				                Otherwise it applies.

To whom ? And is the business justification solely cost driven ? In which case,
what are perceived as the benefits that 095 will give us that we would not have
otehrwise enjoyed ?

>    Standards are not absolutes. They are reference points from which
>    discussions about justifiable deviations can begin.

Surely 095 is put forward as an absolute if 1. is true ?

In which case, Laurie's specific concerns raise their head again.

If the Std is not an absolute, should it not be called a guideline and treated
as such ?    
    
But, as I said, I feel the issue is bigger than just 095.

M. -  Solent, England, Not upset.

>    Consider the different status applications could be in:-
>    1. New and not implemented           --  	DEC Standard 95 applies 
>    2. Old and to be retired (legacy)    --     DEC Standard 95 does not apply
>    3. In developement or functional rev -- 	Business justification as
>    					        why DEC 095 is not
>    					        appropriate ( cost,etc)
    
    What about not new, but not about to be retired, and not being
    drastically changed? In other words, applications already in place
    for which there are not plans of retirement. I have to believe
    a great many (most?) fall into that category. What is the
    justification *for* 095? Where is the gain/payback?
    
    John

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     05-Feb-1992 04:28pm CET
                                        From:     John HARRISON @FYO
                                                  HARRISON AT FNYA1 @EHQMTS @FYO
                                        Dept:     Information Management
                                        Tel No:   (885)-6818

TO: See Below

Subject: U:I: DEC-std 095 - Implementation and Compliance.



        *********************************************************
        PLEASE ENSURE THAT THIS MESSAGE IS PASSED TO ALL RELEVENT
        PEOPLE WITHIN YOUR ORGANISATIONS - many thanks.
        *********************************************************


After considerable feedback from development and portfolio groups, the 
European IM&T Policay Board Meeting in December, discussed the compliance 
to DEC-std 095 and the following agreement was reached -

the elements which refer to naming conventions and directory structures 
(i.e. requiring significant design changes) can be excluded from 
compliance for existing applications.
However, a documented justification for such non-compliance MUST be 
provided in the event of subsequent Application Audit.
It is expected that existing applications will be compliant with ALL 
other elements of the standard .

All new applications (those which have NOT passed the design phase before 
the end of February 1992) must be compliant with ALL elements of the 
standard - this is based on the fact that the original announcement for 
the standard was made in June of 1991.

Where major re-engineering is scheduled to take place on existing 
applications, it is expected that an attempt to achieve full compliance 
be made, and that any reasons for non-compliance are justified in writing 
for possible future reference by audit.

It is on the basis of this agreement that internal audit will carry out 
applications audits after the 1st. March 1992.


Many thanks and best regards - John.


Distribution:


TO:
ALLEN ATWELL @VBO   Daniel COETSIER @FY MICHEL CRUBEZY @EVO steve fuller @geo
FREDERIC GODET @NEU BARBARA HUCKLE @UCG Brad LENTZ @FYO     franz peter @rto
christiane quarterm BERND STEPHAN @RTO  MARCO VACCARO @MIO  GHISLAIN DE VINCK @
CHARLES WHITEHEAD @
CC:
Alfonso DIIANNI @FY martin kelmanson @r Dave TOUGH @FYO     andrew tweedie @ayo
rob watts @geo

    

    I have already commented on that memo in my reply to John Newman, who
    copied it in the body of the text in his earlier reply. In my opinion,
    it confuses the matter further. Please see my earlier reply for
    details.
    
    I shall comment more fully on your earlier notes later, I've run out of
    time.
    
    Laurie.

    Right, I have read through all the replies here carefully this time
    and see that we indeed have a lot of confusion (which I seemed
    to add to - apologies).
    
    Now I will make the following offer. If the European contingent will
    get together (logically that is) and put a well reasoned,objective,
    constructive proposal as to how we should move forward on this issue I 
    will ensure it gets reviewed at the next IM&T policy board meeting.
    
    I am not saying that this will change anything, or that I agree with
    all thats said, just that I will ensure that it has visibility and
    a response. This is probably a better course of action than trying
    resolve it here.
    
    Given the level I would be taking this to, I wouldn't expect to see any
    disclaimers like my "my manager doesn't necesserily agree to this"
    
    Its up to you if you wish me facilitate this. I await you response.
    
    Regards,
    
    Chris
                        

    Laurie, 
    
    Nice reply, and I very much agree and support you view that
    that the most appropriate channel to drive this issue is back through
    your management chain. The only question I could ask, is if you believe
    that why aren't you?
    
    The reason I made the comment about disclaimers is excactly the point
    you make. It may be there are very valid reasons why you management
    have chosen to accept this Standard and support it. If that is the
    case then the only appropriate course of action would be for you and
    your colleagues to express your concerns and help them understand
    the issues and suggest the actions they could take.
    
    As for not wanting to "go round" you manager I am afraid in a way you
    already are by expressing your views in a public notes file. Thats not
    a criticism, merely a statement of reality. I have read it, I am one of
    those people up there with the other people on the dist list, and its my
    job to try resolve this type of issue. Therefore the wheels are already 
    in motion.
    
    Again I will help in anway I can to ensure resolution of this
    conflict. But I am not sure yet where in reality it lies.
    
    
    
    Chris
    
       

    Without meaning to interrupt the flow of debate, may I just ask for
    some clarification . . .
    
    Where _exactly_ does this standard apply? From previous notes, I got
    the distinct impression that this "DEC STD 095" applies to all
    programming effort _anywhere_ in the corporation.
    
    Does this now mean:
    
    	that	Engineering will use the standard in development
    		of layered products? (and retrofit it to existing, 
    		non-retired layered products, as well?)
    
    	and	SWAS will use it in developing software projects for 
    		customers?
    
    	and	Internal applications groups will use it?
    
    
    Or does it only apply to a sub-set of the above?
    
    If this question has already been answered in the preceding replies,
    then please point me to the relevant reply; I'm afraid that I have
    found the discussion so far to be somewhat confusing.
    
    Regards,
    
    
    n.
    
    

	THIS NOTE HAS BEEN POSTED AT THE REQUEST OF DAN INFANTE, VP IM&T

    
    As the responsible manager for Digital's Internal Systems development, 
    I have read your Notes correspondence regarding DEC STD 065 and 095.
    
    You can be assured many hours of heated debate from across the World 
    went into discussing both the technical feasibility and the 
    implementation of these policies.
    
    My staff will respond to specific concerns raised and Peter Cook, IM&T 
    Manager for Europe, should receive feedback and communications 
    regarding concerns relating to local interpretation.
    
    If you would like to communicate directly to me my address is:
    
    	Dan Infante @MSO or my VAX mail account is CORMTS.
    
    Regards,
    
    Dan Infante 

                    DIGITAL INTERNAL USE ONLY Document

    >So why can't Infante post his own reply?
    
    1. Where did it say that this (part of a memo?) was a direct
       reply to this conference?
    
    2. Whether it was meant as a reply in this conference or not is
       not as important as the fact that Dan has stated his position
       and offered those who differ to discuss with him their opposition.

    A quick update here.
    
    I just left a meeting attended by other people from our group in
    Belgium, and by John Newman, John Harrison, and Dave Tough. Yesterday
    they were at the Solent in the UK, and tomorrow they will be at
    Ferney-Voltaire in France. 
    
    There will be an announcement on the official status of DECSTD 095 at
    some time in the near future. I won't pre-empt that any more than to
    say the retro-fitting is seen as inappropriate, and that the standard
    is in the review phase.
    
    I am very pleased with what was a positive, constructive and
    informative meeting. I would also like to say that I appreciate the
    efforts to improve the standard, on the part of those responsible for
    it, John Newman having flown over from the States especially.
    
    Laurie.