EBERARD@ADA20.ISI.EDU (Edward V. Berard) (05/01/87)
It has happened again. Some DoD contractor has contacted our company
for some "Ada training," and has described a "recipe for disaster."
Let me fill you in on the details:
1. Apparently this contractor was awarded a contract even though
there is little evidence to suggest that anyone working on the
software has any real Ada experience. (You know how this works -
pick a scenario: a) the contractor added the word "Ada" to the
list of languages on the resumes at the back of the winning (?)
proposal; b) the contractor assured the naive contracting office
that the technical staff would have "adequate Ada training" by
the time any software was written; c) the contractor used
resumes of "qualified" individuals who are too busy on other
projects to be assigned to the current project, so management
thought that they could either hire someone with the needed
skills by the time the coding started, or provide some absolute
minimum of training to the people actually assigned to the
project.)
2. Not realizing that Ada technology impacts the entire software
life-cycle (including business practices), management has waited
until the coding is about to start to train their technical
staff in what, to the management, is "just another programming
language."
3. Not wanting to waste any money on "software foolishness" (after
all, the management believes that it is the hardware
engineering/mathematics/science that is the "real work"),
management has dictated that the "Ada education" will consist
almost entirely of one week of classroom instruction. Being
somewhat generous, management has also provided some "Booch
books" and some "Alsys tapes" which the technical staff can look
at, on their own time. (I am not knocking the quality or
usefulness of these products, just their misuse.)
4. Since the only computer that has an Ada compiler on it is tied
up with useful work, the one week of training they wish us to
provide is a "hands-off" course. We may provide the students
with some small "paper exercises," but we are being encouraged
to forego any labs so that we can "cram as much of the language
into the heads of the participants as possible."
5. The management is not open to any suggestions on how to improve
the quality of the Ada training. It also happens that some other
well-known Ada experts have attempted to enlighten the
management, but have been rebuffed.
The results of this project can be foretold quite easily.:
- The programmers will find the Ada language to be "large, complex
and confusing." The code they produce will be "AdaTRAN" at best.
There will be a great deal of time spent trying to understand
that "dumb reference manual." Ada books that emphasize syntax to
the exclusion of software engineering will become prized
possessions. Especially valuable will be books and references
which treat Ada as "a superset of Pascal."
- The programmers will find that the Ada development system is
confusing to use. Since it is likely that the design will be in
a constant state of revision, the specification parts of the Ada
program units will change fairly often, necessitating frequent
re-compilation and relinking. As the amount of code grows, the
time spent re-compiling and relinking will quickly reach an
intolerable level. Frequent references will be made to the large
amount of object code produced, and its inefficient running
speed. But after all, isn't that what one would expect from such
a large language?
- The programmers will find many features of the Ada language to
be extremely bothersome. There will be frequent complaints about
strong typing, private types (if they are used at all), the time
for task rendezvouses, and those strange generic things.
- More source code will be produced than for a comparable project
written in FORTRAN or Pascal. The detractors of Ada will
gleefully point to this as an expected result.
- The project will be late, overbudget, and the software will not
perform at anywhere near the original specifications. Looking
for a scapegoat, management and the technical staff will grab
the first inanimate object they can find (you guessed it --
Ada), and blame it for any shortcomings or project failures.
The contracting office, being equally naive about Ada
technology, will accept without question that Ada is the
culprit.
There will, of course, be many other problems, but let us now focus
our attention on the root causes.
The Ada language was designed by first identifying a number of
desirable software engineering features (e.g., data abstraction,
information hiding, and encapsulation), and then incorporating these
features into a programming language. Since a good number of these
concepts are foreign to most programmers and managers, it comes as no
surprise that the concepts are often abused, if they are used at all.
Many advocates of Ada technology have pushed the language, and ignored
the software engineering. Yes, there have been some people within the
DoD, and outside of the DoD, who have stressed software engineering,
but their voices have been lost in the din. [Note the on-again,
off-again funding for STARS.] Part of the blame lies at the feet of
the DoD for not stressing software engineering strongly enough.
Within the Ada Joint Program Office (AJPO) is the Ada Software
Engineering and Education and Training (ASEET) group. Hopefully, one
of ASEET's goals is to define minimal qualifications for an Ada
software professional. This should be in addition to definitions for
course content in an industry targeted Ada and software engineering
training curriculum. Without any guidance, contractors are free to
train (or not train) their technical staffs in any manner they choose.
Further, contracting offices continue to have no idea as to what
constitutes a qualified Ada professional.
Of course, I am not going to let the contractor's management off the
hook. Unfortunately, they learned a long time ago that software
quality was little more than a buzzword. (Note: Much is known about
software quality, including how to measure it. Sadly, this technology
seems to be largely ignored.) They seem to get paid regardless of the
"quality" of the software product. Is it any wonder why they view
software as a necessary evil, and software engineering training as a
useless luxury? So what if the software fails, so long as the hardware
holds up.
There is a one-word definition for learning: change. The hope behind
Ada technology is that this change will be for the better. Until there
is a greater recognition that Ada education and training is different,
the change may not be what the proponents of the new technology have
predicted.
-- Ed Berard
(301) 695-6960
-------