re:state of Ada / Paige memo

re:state of Ada / Paige memo

[Ed Falis]

By the way, how many of the "overall life cycle cost analyses"
recommended by the memo to decide the right language do you think
actually happened in more than a desultory fashion?  I'm not aware of
any, and I've worked for Ada vendors for the last 25 years.

Re: state of Ada / Paige memo

[Jeffrey R. Carter]

Ed Falis wrote:
> By the way, how many of the "overall life cycle cost analyses"
> recommended by the memo to decide the right language do you think
> actually happened in more than a desultory fashion?  I'm not aware of
> any, and I've worked for Ada vendors for the last 25 years.

The fact that this requirement is not enforced is the true evidence of 
the DOD's attitude towards Ada and SW eng in general.

-- 
Jeff Carter
"Don't knock masturbation. It's sex with someone I love."
Annie Hall
45

Re: state of Ada / Paige memo

[Gary Scott]

Jeffrey R. Carter wrote:
> Ed Falis wrote:
> 
>> By the way, how many of the "overall life cycle cost analyses"
>> recommended by the memo to decide the right language do you think
>> actually happened in more than a desultory fashion?  I'm not aware of
>> any, and I've worked for Ada vendors for the last 25 years.
> 
> 
> The fact that this requirement is not enforced is the true evidence of 
> the DOD's attitude towards Ada and SW eng in general.

I deal with DOD a lot.  I don't think this is generally true.  Industry 
rebellion had something to do with it (ready trained supply of C 
programmers (er hackers)).

> 


-- 

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows 
it can't be done.

-- Henry Ford

Re: state of Ada / Paige memo

[jimmaureenrogers]

On Aug 30, 6:48 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:

>
> I deal with DOD a lot.  I don't think this is generally true.  Industry
> rebellion had something to do with it (ready trained supply of C
> programmers (er hackers)).

I have also had some experience with the DoD. Industry rebellion is
not
a valid excuse. DoD Purchasing Organizations can easily require cost
and
quality analyses of chosen tools, including programming languages. The
fact that they do not is an indication that contracts are often
produced
and supervised by very junior officers with little or no experience
in
the field. Those officers learn are taught their jobs by interacting
with
the Industry contractors. Those contractors are adept at feeding loads
of
bovine excrement to the junior officers as though it was real
information.

Similar problems arise in NASA contracts. Most of the engineers who
built
human-rated space vehicles for NASA are retired or dead. The current
crop
of NASA engineers relies upon its contractors to create requirements.
Those contractors make more money when a project requires change
orders
due to faulty requirements, faulty design, faulty implementation, and
schedule slips than they do by producing the desired product according
to
the original contract. Many (not all) contractors do not want to use a
reliable language when more money can be made using an unreliable
language.

Jim Rogers

Re: state of Ada / Paige memo

[Brian Gaffney]

<jimmaureenrogers@worldnet.att.net> wrote in message 
news:1188524716.464116.221000@m37g2000prh.googlegroups.com...
> On Aug 30, 6:48 pm, Gary Scott <garylsc...@sbcglobal.net> wrote:
>
>>
>> I deal with DOD a lot.  I don't think this is generally true.  Industry
>> rebellion had something to do with it (ready trained supply of C
>> programmers (er hackers)).
>
> I have also had some experience with the DoD. Industry rebellion is not
> a valid excuse. DoD Purchasing Organizations can easily require cost and
> quality analyses of chosen tools, including programming languages. The
> fact that they do not is an indication that contracts are often produced
> and supervised by very junior officers with little or no experience in
> the field. Those officers learn are taught their jobs by interacting with
> the Industry contractors. Those contractors are adept at feeding loads of
> bovine excrement to the junior officers as though it was real
> information.
>

Is this related to the people involved or the organizations?  If the 
purchasing organization is responsible for purchasing only, and the people 
move on to the next one once a purchase is complete, life cycle analysis 
doesn't have a whole lot of meaning to them.  Even if the people wanted to 
honestly evaluate it, they typically have no experience in that little phase 
after purchase called "maintenance".

You might (or might not) get a different picture if you looked at cases 
where the organization responsible for maintenance has a substantial role, 
such as upgrades to existing systems.

--Brian

Re: re:state of Ada / Paige memo

[anon]

J.A. "Drew" Hamilton, Jr., Ph.D who was the last directory of 
the Ada Joint Program Office put it the way it was since he 
was apart of it.

https://listserv.dtic.mil/listcgi/wa?A2=ind0608&L=it-cop-l&P=2765



Everybody does "overall life cycle cost analyses".  In the case of the US 
government all departments it is every four to six years, for the long term 
analysis but it is every year for the short term aka the fiscal budget. 

Every company want to buy the equipment once and unless something 
happens to they would like to keep it forever. But in the real world, that 
is not so. The office computer hardware is obsolete in 18 months to 2 
years.  The life of the software depends upon the application.  

Microsoft, as a shelf life of 2 to 3 years and at it end it can cause a 
complete re-purchasing of all software. Other OSes have different time 
table than Microsoft.

An accounting system last until the company's accounting changes, such 
as expansion into other business areas or merges with others. Or the 
accounting system can become obsolete at the next operating system 
release.

Another example is an analyzer system for cars, once these cars are no 
longer in the general area, then this system become obsolete.  That 
might be 5, 10, or even longer. Or it could be immediate, if no one 
drives this car in the shops area.

In a true simplistic example, every time one goes to the market they does 
a cost analyses. In food, its brand, packing, and flavor. Now in electronic 
it might be features version price. And in all case its shelf and usage life. 

Like today, buying a VCR when DVDs are replacing VCR. But if price is a 
factor or easy of find equipment to play the program on, you might choose 
VCR. Because how many grandparents have DVD players. Of course, this 
is changing all the time, because what next after HD-DVD. You can make 
book on it, there is something and it will make all forms of DVD obsolete.

"overall life cycle cost analyses" is a continual thing that is always being 
update by many factors. One factor change it might trigger an action based 
on the current "cost analyses" or for others it might take two or three 
factor changing to trigger such action.

As for Ada and the E. Paige (retired in 88) memo, well to many friends 
listen to their ex boss. They gave his opion more weight in a 
government decission than he should of had. 






In <PM000438DCAFA0934B@tilopa.unknown.dom>, Ed Falis <falis@verizon.net> writes:
>By the way, how many of the "overall life cycle cost analyses"
>recommended by the memo to decide the right language do you think
>actually happened in more than a desultory fashion?  I'm not aware of
>any, and I've worked for Ada vendors for the last 25 years.