Hey, blame the private sector!

Hey, blame the private sector!

[Colin James 0621]

  
While Greg et al assert (probably correctly) that the Ada compiler
vendors have not "sold
" outside the mandated world, the fact that Ada has not caught on and
lit up the private sector in the US (as has C) is more the fault of the
private sector choosing to be Ada-ignorant than anything else.  The US
banking industry demonstrates this exactly.  How many of the gravitationally
challenged MIS leaders at banks have read Paul Strassmann's "The Business
Value of Computers"?  Indee, have Greg et al read it?
 
So lay off the Ada compiler vendors and government offices, and lay it
on heavy and squarely to  the dopes with multiple academic degrees in the
private sector who prefer inconsistent results at runtime from bloated 
write-once C code.

Re: Hey, blame the private sector!

[Gregory Aharonian]

>banking industry demonstrates this exactly.  How many of the gravitationally
>challenged MIS leaders at banks have read Paul Strassmann's "The Business
>Value of Computers"?  Indeed, have Greg et al read it?
 
    I have read most of everything Paul Strassman has written or said.  All
I know is that everytime he was interviewed in the computer media about 
Defense software, not once did he mention Ada.  So I suspect anything he
says about Ada because it is obvious he is embarassed to be associated
with the language.  Give me guys like General Kind who know how to advocate
a language.  Until the Mandated world starts pushing Ada much more openly,
all business people are going to think when they see ADA is the Disability
Act.  PEOPLE DON'T BUY WHAT THEY HAVE NEVER HEARD OF.

>So lay off the Ada compiler vendors and government offices, and lay it
>on heavy and squarely to  the dopes with multiple academic degrees in the
>private sector who prefer inconsistent results at runtime from bloated 
>write-once C code.

By dopes, do you mean any of the following millionaires and billionaires who
made their money, run successful companies, and practice what they preach
with regards to C/C++, without having to trough at tax dollars:
	Bill Gates, Phillipe Kahn, Steve Jobs, etc,etc, etc
and their companies
	Microsoft, Borland, Computer Associates, Lotus, etc,etc,etc

I wish I could be as big a dope as Bill Gates.  He has made billions on
C/C++ efforts, while the Mandated world has lost billions on Ada projects
(including WAM,STANFINS,FAA, and probably RCAS).
Greg

-- 
**************************************************************************
 Greg Aharonian
 Source Translation & Optimization
 P.O. Box 404, Belmont, MA 02178

Re: Hey, blame the private sector!

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!zaphod.m]

In article <SRCTRAN.93May24122703@world.std.com>, srctran@world.std.com
(Gregory Aharonian) writes:
|>
|>>banking industry demonstrates this exactly.  How many of the
|>gravitationally
|>>challenged MIS leaders at banks have read Paul Strassmann's "The
|>Business
|>>Value of Computers"?  Indeed, have Greg et al read it?
|> 
|>    I have read most of everything Paul Strassman has written or said.
|>All
|>I know is that everytime he was interviewed in the computer media
|>about 
|>Defense software, not once did he mention Ada.  So I suspect anything
|>he
|>says about Ada because it is obvious he is embarassed to be
|>associated
|>with the language.

I put the 'Ada question' to Mr Strassman recently, and his response (I
paraphrase) was that while Ada was a good technology, technology alone 
will not solve the DoD's software development problems.  Mr Strassman 
felt that the keys to getting this problem under control involved
process definition and performing solid functional economic analysis
as the basis for information systems development.

His point was that when you develop 25 systems that fill the *same*
function, then it doesn't really matter what language/technology/
mystical incantations you use to develop them, does it?   You're 
wasting time and money.

So I think that it is more accurate to characterize his feelings
towards the Ada question as "that's not the issue, stupid", as opposed 
to embarassment.

Just IMHO and $0.02 worth, of course.
-- 
Scott McCoy     Harris ISD 
Staff Eng-SW    Opinions expressed are my own

Re: Hey, blame the private sector!

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!zaphod.mps.o]

In article <1993May24.183623.22527@mlb.semi.harris.com> smccoy@dr3w.ess.harris.
com (Scott McCoy) writes:
>I put the 'Ada question' to Mr Strassman recently, and his response (I
>paraphrase) was that while Ada was a good technology, technology alone 
>will not solve the DoD's software development problems.  Mr Strassman 
>felt that the keys to getting this problem under control involved
>process definition and performing solid functional economic analysis
>as the basis for information systems development.
>
>His point was that when you develop 25 systems that fill the *same*
>function, then it doesn't really matter what language/technology/
>mystical incantations you use to develop them, does it?   You're 
>wasting time and money.
>
>So I think that it is more accurate to characterize his feelings
>towards the Ada question as "that's not the issue, stupid", as opposed 
>to embarassment.
>
Well, now I'm REALLY confused. Why does Mr. Strassman espouse process
definition as a key to solving DoD software development problems but
minimalize the useage of the common (mandated) language (and its associated
processes, e.g., compilers, debuggers, etc.) as another consideration
in solving the perceived problem? I am puzzled by your choice of
words ("mystical incantations" "wasting time and money" and "that's
not the issue, stupid" (stupid!!?)) in the context of any, never
mind only DoD, software development and language consideration.

I have a few years experience in software development at McDonnell
in St. Louis, and I will be the first to agree that (IMHO) Mac at
least could stand some improvement in process definition, but this
isn't information systems development but avionics systems. If Mr.
Strassman's objective is to allow (or, OK, FORCE) the contractors
to develop defined processes, I think that is a Good Thing. But if,
as I suspect, the goal is to present some sort of mandated processes
to the contractors as a fait accompli, well, I don't think that will
help the problem at all. How on earth did we get to the point of
developing 25 systems that fill the *same* function, anyway?

If Ada/language isn't THE problem with DoD software development, I can't
help but to think it's a component of the problem. And I don't think 
that Greg (or most of the posters here) think that Ada qua Ada is 
A Problem, but that the DoD's handling of it IS, and your paraphrasing
of Mr. Strassman's responses sounds as though he would rather talk 
about anything BUT Ada and the DoD.

-------------------------------------------------------------------
| Mark Shanks                          |           
| Principal Engineer                   |    All opinions mine,  
| 777 Displays                         |        of course.
| shanks@saifr00.cfsat.honeywell.com   |          
| "We have such sights to show you..." |            
-------------------------------------------------------------------

Re: Hey, blame the private sector!

[Michael Feldman]

In article <1993May24.195810.796@saifr00.cfsat.honeywell.com> shanks@saifr00.cf
sat.honeywell.com (Mark Shanks) writes:
>
>If Ada/language isn't THE problem with DoD software development, I can't
>help but to think it's a component of the problem. And I don't think 
>that Greg (or most of the posters here) think that Ada qua Ada is 
>A Problem, but that the DoD's handling of it IS, and your paraphrasing
>of Mr. Strassman's responses sounds as though he would rather talk 
>about anything BUT Ada and the DoD.
>
Well, since he's not in the DoD any more (he left with the change of
administration), I guess it's moot now, isn't it? Who has replaced him
at DoD? And what's Strassmann doing now? Did he go back to Xerox?

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"The most important thing is to be sincere, 
and once you've learned how to fake that, you've got it made." 
-- old show-business adage
------------------------------------------------------------------------

Re: Hey, blame the private sector!

[Cheshire Cat]

In article <1993May24.195810.796@saifr00.cfsat.honeywell.com>,
shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
|>Well, now I'm REALLY confused. Why does Mr. Strassman espouse process
|>definition as a key to solving DoD software development problems but
|>minimalize the useage of the common (mandated) language (and its
|>associated
|>processes, e.g., compilers, debuggers, etc.) as another consideration
|>in solving the perceived problem? 

Let me clarify.  Throwing Ada at the DoD's software procurement and 
development problems won't treat the disease, just a symptom.  Use of
a standard language and toolset is a GoodThing (tm), but if you don't
know what the big-picture requirements are (that the system is trying
to solve), then it really doesn't matter what tools you use.

|>I am puzzled by your choice of
|>words ("mystical incantations" "wasting time and money" and "that's
|>not the issue, stupid" (stupid!!?)) in the context of any, never
|>mind only DoD, software development and language consideration.
|>

The last quote is a paraphrase of *the* Bill Clinton campaign slogan
("It's the economy, stupid").

|>If Mr.
|>Strassman's objective is to allow (or, OK, FORCE) the contractors
|>to develop defined processes, I think that is a Good Thing. 

Yep, that's it.  A defined and proven process should give predictable
results.

|>How on earth did we get to the point of
|>developing 25 systems that fill the *same* function, anyway?

Have you ever looked in DDRS, the 'standard' data dictionary?  How did
we get 17 different formats for 'address',  7 for 'date',  and multiple
'names'?  The Not-Invented-Here Synydrom, that's how!  (BTW, while I
am not sure that my numbers are exact (i.e., 17), they are in the
ball-park.)

|>If Ada/language isn't THE problem with DoD software development, I can't
|>help but to think it's a component of the problem. 

Difference of perspective.  The problem is that unless you have an
economic reason for building/procuring software, then why are you doing
it?  The Ada issue is a question of the most appropriate solution, not
the problem.

|>your paraphrasing
|>of Mr. Strassman's responses sounds as though he would rather talk 
|>about anything BUT Ada and the DoD.
|>

Mr Strassman felt that Ada is not the central issue with DoD software
development and procurement.

And to answer Mike Feldman, Mr Strassman has formed his own consulting
company (Strassman, Inc.).

-- 
Scott McCoy     Harris ISD 
Staff Eng-SW    Opinions expressed are my own

Re: Hey, blame the private sector!

[Michael Feldman]

In article <1993May25.133837.19947@mlb.semi.harris.com> smccoy@dr3w.ess.harris.
com (Cheshire Cat) writes:
>
[...]

>Mr Strassman felt that Ada is not the central issue with DoD software
>development and procurement.

I think the point was that he felt it wasn't an issue at all.

>
>And to answer Mike Feldman, Mr Strassman has formed his own consulting
>company (Strassman, Inc.).

Ah, yes. I should've guessed. Don't they all. And so the door revolveth.
(And he _does_ spell it Strassmann - two n's.)

Mike Feldman

Re: Hey, blame the private sector!

[dog.ee.lbl.gov!network.ucsd.edu!usc!cs.utexas.edu!wupost!darwin.sura.net!]

In article <1993May24.195810.796@saifr00.cfsat.honeywell.com>,
shanks@saifr00.cfsat.honeywell.com (Mark Shanks) writes:
|>Well, now I'm REALLY confused. Why does Mr. Strassman espouse process
|>definition as a key to solving DoD software development problems but
|>minimalize the useage of the common (mandated) language (and its
|>associated
|>processes, e.g., compilers, debuggers, etc.) as another consideration
|>in solving the perceived problem? 

Let me clarify.  Throwing Ada at the DoD's software procurement and
development problems won't treat the disease, just a symptom.  Use of a
standard language and toolset is a GoodThing (tm), but if you don't
know what the big-picture requirements are (that the system is trying
to solve), then it really doesn't matter what tools you use.

|>I am puzzled by your choice of
|>words ("mystical incantations" "wasting time and money" and "that's
|>not the issue, stupid" (stupid!!?)) in the context of any, never
|>mind only DoD, software development and language consideration.
|>

The last quote is a paraphrase of *the* Bill Clinton campaign slogan
"It's the economy, stupid".

|>If Mr.
|>Strassman's objective is to allow (or, OK, FORCE) the contractors
|>to develop defined processes, I think that is a Good Thing. 

Yep, that's it.  A defined and proven process should give predictable
results.

|>How on earth did we get to the point of
|>developing 25 systems that fill the *same* function, anyway?

Have you ever looked in DDRS, the 'standard' data dictionary?  How did
we get 17 different formats for 'address',  7 for 'date',  and multiple
'names'?  The Not-Invented-Here Synydrom, that's how!  (BTW, while I am
not sure that my numbers are exact (i.e., 17), they are in the ball-park.)

|>If Ada/language isn't THE problem with DoD software development, I can't
|>help but to think it's a component of the problem. 

Difference of perspective.  The problem is that unless you have an
economic reason for building/procuring software, then why are you doing
it?  The Ada issue is a question of the most appropriate solution, not
the problem.

|>your paraphrasing
|>of Mr. Strassman's responses sounds as though he would rather talk 
|>about anything BUT Ada and the DoD.
|>

Mr Strassman felt that Ada is not the *central* issue with DoD software
development and procurement.

And to answer Mike Feldman, Mr Strassman has formed his own consulting
company (Strassman, Inc.).

-- 
Scott McCoy     Harris ISD 
Staff Eng-SW    Opinions expressed are my own

Re: Hey, blame the private sector!

[Laurence VanDolsen]

In article <1993May24.195810.796@saifr00.cfsat.honeywell.com> shanks@saifr00.cf
sat.honeywell.com (Mark Shanks) writes:
>Well, now I'm REALLY confused. Why does Mr. Strassman espouse process
>definition as a key to solving DoD software development problems but
>minimalize the useage of the common (mandated) language (and its associated
>processes, e.g., compilers, debuggers, etc.) as another consideration
>in solving the perceived problem? I am puzzled by your choice of
>words ("mystical incantations" "wasting time and money" and "that's
>not the issue, stupid" (stupid!!?)) in the context of any, never
>mind only DoD, software development and language consideration.
>
 If Mr.
>Strassman's objective is to allow (or, OK, FORCE) the contractors
>to develop defined processes, I think that is a Good Thing. But if,
>as I suspect, the goal is to present some sort of mandated processes
>to the contractors as a fait accompli, well, I don't think that will
>help the problem at all. How on earth did we get to the point of
>developing 25 systems that fill the *same* function, anyway?
>
>If Ada/language isn't THE problem with DoD software development, I can't
>help but to think it's a component of the problem. And I don't think 
>that Greg (or most of the posters here) think that Ada qua Ada is 
>A Problem, but that the DoD's handling of it IS, and your paraphrasing
>of Mr. Strassman's responses sounds as though he would rather talk 
>about anything BUT Ada and the DoD.

I cannot speak for Mr. Strassman.  The main thrust of current thinking
in the DoD, as evidenced by keynote addresses at various conferences and
other indications, seems to be that process maturity is a high payoff
area of concentration. (I happen to agree.)  Further, there seems to be
a consensus that Ada, more than most other languages, tends to be
supportive of disciplined process.  There seems to be a growing
recognition that the Mandate has outlived its usefulness.  There does
not seem to be a strong push to rescind it so much as to remind
everybody that it has a built-in provision for chossing a non-Ada
approach.  "All ya gotta do" is show that the use of some other language
will have cost and risk advantages over Ada.  Critics howl that nobody
has ever had to prove the cost-effectivenes of Ada, and they are right,
but who ever said life was fair?

There is a tendency, often seen on the net, to take any statement by any
single Govt. representative as being a very significant indicator of DoD
direction.  We must remember that the DoD is not an effective
dictatorship.  People have, and enunciate, a broad range of opinions.
Which of these turns out to be significant is usually not known for
several years after the fact, when the statements can be viewed in
historical perspective.

Currently, the DoD is funding STARS, the SEI, AJPO, and various reuse
and reengineering initiatives.  These actions are indicative of a
consensus that cost-effective development of reliable software will
benefit from disciplined process and institutionalized reuse, and that a
significant proportion of future software dollars are going to continue
to be tied up in the support of legacy programs.  In all of these areas,
there is a general consensus, but not unanimity, that Ada is the
language of choice for the development of robust systems with minimal
life-cycle support costs.

We got into the habit of building new systems instead of adapting old
ones because:

	It is more fun to start from scratch

	Old systems were very difficult to understand well enough to
	adapt

	Technology support for reengineering and platform portability
	did not support cost-effective reuse

	There were few effective communication mechanisms whereby
	program managers could become aware of reusable assets.

	There were (are) 'territorial imperatives' which make it
	difficult for a program manager to adopt and use something
	from another service, or even another branch of the same service.

The STARS program emphasis on Megaprogramming, and the ASSET, CARDS,
ASR, and other reuse libraires and related support services are all part
of a DoD effort to end-run these difficulties.  We can argue about the
implementation approaches, but I think we can agree that the general
direction in which the DoD is moving is the correct one.

Re: Hey, blame the private sector!

[Laurence VanDolsen]

In article <1993May25.161125.21879@source.asset.com> vand@source.asset.com (Lau
rence VanDolsen) writes:
>In article <1993May24.195810.796@saifr00.cfsat.honeywell.com> shanks@saifr00.c
fsat.honeywell.com (Mark Shanks) writes:
>>
> If Mr.
>>Strassman's objective is to allow (or, OK, FORCE) the contractors
>>to develop defined processes, I think that is a Good Thing. But if,
>>as I suspect, the goal is to present some sort of mandated processes
>>to the contractors as a fait accompli, well, I don't think that will
>>help the problem at all. 

I forgot to address this point in my previous post.

There are a few folks in the DoD who think that mandating a process is
the right way to go.  In the many conversations in which I have been
involved, these people have been shouted down by the majority.  The
consensus is clearly that there must be room for innovation in an
environment of consistent, disciplined, and managed process.  It is
forseen that the most valuable competitive asset of the future may be a
contractor's process.  To mandate adherence to a single process would
stifle progress.

I agree with this approach, but cannot defend, any better than they can,
the premise that the Ada mandate is good while a process mandate would
be bad.

Re: Hey, blame the private sector!

[David Emery]

I am very concerned with the current emphasis in DoD on software
process, as opposed to software product.  Sure, a good process can
help you get a good product, but it is NOT a guarantee.  There are
contractors that I've seen with a very well defined process, who
produce crap in a very predictable way, time after time.  On the other
hand, what do you suppose the SEI CMM rating would be for Richard
Stallman, et.al. at the Free Software Foundation?

Process helps, and the government should take a contractor's process
into account both during award and during subsequent development.  But
the government also needs to keep in mind that it's buying PRODUCT,
and process is only one means to that end.  

				dave

Re: Hey, blame the private sector!

[Laurence VanDolsen]

In article <EMERY.93May25191416@dr_no.mitre.org> emery@dr_no.mitre.org
(David Emery) writes:

>I am very concerned with the current emphasis in DoD on software
>process, as opposed to software product.  Sure, a good process can
>help you get a good product, but it is NOT a guarantee.  

Nothing is a guarantee.  There is a stong positive correlation between
disciplined process and on-time, on-budget, robust software.  The
correlation gets stronger as the size of the development effort and
staff gets larger.

> On the other
>hand, what do you suppose the SEI CMM rating would be for Richard
>Stallman, et.al. at the Free Software Foundation?

Intriguing question.  They would probably conclude that he follows his
proven process religiously.  A lot of the assessment methodology relies
on having the process documented and being able to audit tangible
artifacts which demonstrate adherence to the process.  I suspect that he
works with such a small group that they have, generally, found this
unnecessary.

>Process helps, and the government should take a contractor's process
>into account both during award and during subsequent development.  But
>the government also needs to keep in mind that it's buying PRODUCT,
>and process is only one means to that end.  

I could not agree with you more.  


Laurence L. Van Dolsen - Der fliegender Hollander
My opinions are my own, but you are welcome to them.
Paramax - (805) 987-9302 - vandolsen@cam.paramax.com

Re: Hey, blame the private sector!

[David Emery]

>Nothing is a guarantee.  There is a stong positive correlation between
>disciplined process and on-time, on-budget, robust software.  The
>correlation gets stronger as the size of the development effort and
>staff gets larger.

Citation to the data/analysis, please...  

				dave

Re: Hey, blame the private sector!

[dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!zaphod.mps.o]

In <1993May26.182402.19744@source.asset.com> vand@source.asset.com (Laurence Va
nDolsen) writes:

>In article <EMERY.93May25191416@dr_no.mitre.org> emery@dr_no.mitre.org
>(David Emery) writes:

>> On the other
>>hand, what do you suppose the SEI CMM rating would be for Richard
>>Stallman, et.al. at the Free Software Foundation?

>Intriguing question.  They would probably conclude that he follows his
>proven process religiously.  A lot of the assessment methodology relies
>on having the process documented and being able to audit tangible
>artifacts which demonstrate adherence to the process.  I suspect that he
>works with such a small group that they have, generally, found this
>unnecessary.

Which infers that the FSF would be evaluated at a low CMM level,
which could bar them from being awarded a government contract
that required the contractor to have attained a certain CMM level.

--Rob  spray@convex.com

Re: Hey, blame the private sector!

[Laurence VanDolsen]

In article <spray.738460132@convex.convex.com> spray@convex.com (Rob Spray) wri
tes:
>In <1993May26.182402.19744@source.asset.com> vand@source.asset.com (Laurence V
anDolsen) writes:
>
>>In article <EMERY.93May25191416@dr_no.mitre.org> emery@dr_no.mitre.org
>>(David Emery) writes:
>
>>> On the other
>>>hand, what do you suppose the SEI CMM rating would be for Richard
>>>Stallman, et.al. at the Free Software Foundation?
>
>>Intriguing question.  They would probably conclude that he follows his
>>proven process religiously.  A lot of the assessment methodology relies
>>on having the process documented and being able to audit tangible
>>artifacts which demonstrate adherence to the process.  I suspect that he
>>works with such a small group that they have, generally, found this
>>unnecessary.
>
>Which infers that the FSF would be evaluated at a low CMM level,
>which could bar them from being awarded a government contract
>that required the contractor to have attained a certain CMM level.
>

I am not certain that the result is implied.  It would depend somewhat
on the intelligence and motivation of the evaluators as well as on
characteristics of the FSF processes at which I can only guess.  In any
event, Richard has several other philosophical disagreements with the
DoD business style which might make this a moot point.  BTW, I generally
agree with his positions, as I understand them.  In an ideal world, all
programmer's would be as smart as Richard and all management would be
smart enough to attract and hold such people.