comp.lang.ada
 help / color / mirror / Atom feed
* The U.S. DoD in Software Fantasyland
@ 1989-02-12 22:18 Edward Berard
  1989-02-13 16:47 ` Richard Pettit
  0 siblings, 1 reply; 3+ messages in thread
From: Edward Berard @ 1989-02-12 22:18 UTC (permalink / raw)


THE STORY HAD AN ENCOURAGING BEGINNING

Most of you know how the story begins. It is the early 1970s, and the
U.S. Department of Defense (DoD) has decided that it is spending too
much money for software. To make matters worse, the software is
typically late, overbudget, and filled with bugs. A study is conducted
in 1974, and, in 1975 the Higher Order Language Working Group (HOLWG)
is set up. The mission of the HOLWG is to first define "good software
engineering" and then to identify programming languages which
supported the same.

By 1977, it became evident that existing programming languages fell
far short of the desired objectives. It was decided that a new
language was both desirable and feasible. Along the way, some realized
that a programming language would not be enough. Concepts like the Ada
Programming Support Environment (APSE), the Software Engineering
Institute (SEI), Software Technology for Adaptable Reliable Systems
(STARS), and Ada Software Engineering Education and Training (ASEET)
would also be needed. These, and other, parts of the Ada technology
infrastructure were created and put in place.

A good number of spokespersons toured the countryside with slides
showing how important and critical software was to the welfare of
modern weapons systems. They explained that the demand for software
was increasing exponentially, and that software was being used in
increasingly critical applications. They stressed that the DoD wanted
not only more software, but also more reliable, and less expensive
software. The entirety of the Ada effort -- not just the programming
language -- was intended to address the increased emphasis and
dependency on software.

It appeared hopeful that the software community would get the message
that the DoD was serious about better engineered software.

THINGS HAVE NOT GONE TOO WELL

Almost from the very beginning, the software community, as a whole,
thought that the DoD was peddling "some new programming language snake
oil." Although there was some attempt to publicize the other aspects
of the technology (e.g., SEI, STARS, and ASEET), these efforts were
very weak. There is still a great deal of confusion. Anti-Ada
mythology is rampant, e.g.: "Ada is PL/1 re-visited," "all Ada
compilers generate object code which is 10 times larger and slower
than that generated by most C compilers," and "only those who are
forced to use the Ada language are the ones using it."

Some of Ada's "friends" have not been very helpful either. Pro-Ada
mythology is also present, e.g., "merely writing an application in Ada
makes that application highly portable and reusable," "conversion to
Ada is relatively quick and easy," "mere exposure to the language will
cause programmers to see the underlying software engineering
principles and will result in improved software."

There is still a great deal of confusion about what Ada is all about.
Although the SEI is alive and well, many DoD managers and independent
contractors have little idea of what it is and what it can do for
them. STARS is having a very difficult time. The term APSE has been so
misused as to be almost meaningless. Contracting offices have little
guidance on determining the level of Ada proficiency for a potential
contractor.

THAT IS NOT THE WORST OF IT

One of the biggest problems in the DoD's attempt at a technology
transition is that it sends out conflicting messages, i.e.:

	- Sound software and excellence in software engineering are
	  very important -- in fact, crucial

	- The creation, maintenance, management, and other activities
	  associated with software are not that important -- in fact,
	  the approaches we have used in decades past are sufficient.

In my travels, I have come across many frustrated government software
engineers. Consider the following examples:

	- At a Naval installation on the west coast: After a number of
	  tours at sea, some navy personnel were offered "desk jobs."
	  These positions were essentially management positions, with
	  some of the positions being software-related. It was made
	  quite clear that if a software position was selected, the
	  person selecting the position would no longer be considered
	  a professional, i.e., software personnel were not
	  professionals. 

	- At an Army installation: I met more than one person with a
	  masters degree in computer science who was not considered a
	  professional because they had elected to work with software.
	  Curiously, someone with a bachelors degree in electrical
	  engineering could work with software, and still be
	  considered a professional -- as long as they were hired as
	  an electrical engineer.

	- At an Air Force base: An Air Force officer informed me that
	  even though his duties seemed to require a great deal of
	  college-level coursework (even a degree in computer
	  science), his position was not considered to be a
	  professional one. The message was that just about anyone
	  with "a little training" could fill his shoes.

The training policies, procedures, and qualifications within the DoD
remain largely as they have been for the past twenty years. It seems
that all that is required to gain entrance to most software training
is a high school diploma. Many managers actually believe that after a
few weeks of classroom training, someone is qualified to work as a
"software engineer." (If you can write code that compiles and
executes, what else is required?)

In short, although there have been vast advances in software
engineering technology, and software is being used in increasingly
critical applications, the DoD seems to feel that the attitudes,
training, and policies that were appropriate for software a quarter of
a century ago are still largely appropriate today. This is not only
unacceptable, it is dangerous.

WHAT IS NEEDED

First, the DoD must realize that it is 1989 -- not 1965. Large advances
in software engineering technology have been made. Much of this
technology requires college-level education if it is to be used
effectively. The DoD must begin to treat those who choose software
engineering (as a vocation) as professionals.

Most importantly, if the DoD contends that software is critical, it
must carry this concept to its logical conclusion and place stricter
qualifications on those who engineer and manage software.

				-- Ed Berard
				   Phone: (301) 695-6960
				   FAX: (301) 695-7734

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~1989-02-13 20:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1989-02-12 22:18 The U.S. DoD in Software Fantasyland Edward Berard
1989-02-13 16:47 ` Richard Pettit
1989-02-13 20:36   ` William Thomas Wolfe,2847,

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox