> I realize this is a different point-of-view from that espoused by many on
> the committee, but I am persuaded that linguistic continuity is an important
> feature of successful software construction, and this continuity should
> include early selection of an appropriate software engineering language.
Various members of the committee might agree with you. But this
does not by itself provide a business case for a mandate, particularly
given the costs inherent in imposing a mandate from above.
> To establish and enforce a policy in favor of a particular language, such
> as Ada, the DoD can look forward to better adherence to linguistic
> continuity for the entire project.
This is a non-sequitur to me. There is no mandate, nor has
there ever been, to use Ada for requirements analysis, design, etc.
Trying to force contractors to adopt "linguistic continuity"
would be yet more interference in their development process.
> This is not unlike many commercial organizations which standardize on
> some language, often choosing that language based on criteria that
> come close to being whimsical. The DoD should continue to standardize
> on Ada because it is the right thing to do. It is baffling to see a
> report as important as the NRC report based on admittedly inconclusive data.
When data are inconclusive, that doesn't mean you can afford to make
no decision at all. The committee admits that they needed to make use
of anecdotal evidence, expert testimony, professional experience, etc.,
to reach their conclusion. Few decisions in life can rely on hard-and-fast
> I would be interested in seeing some of the members of the study group
> write their own views, polling the jury so to speak, to see where they
> stand with regard to the very odd recommendations published in the final
I think I can safely say that there was very little support for
leaving the DoD Ada policy, with all its warts and waivers, as is.
We were all over the map initially as to the way to improve it, but
after a lot of testimony and a lot of analysis, a consensus developed
around the position identified in the committee's report.
I suspect that if you put together another panel, again containing
a balance of software engineering experts, defense contractors, tool vendors,
and those with direct DoD experience, you would end up again with
a position that would _not_ be "mandate Ada for all DoD applications,
big or small."
The big change since Ada was first commissioned is not the
change in the nature of the custom software development
process (which really hasn't changed that much), but rather in the
explosion in off-the-shelf (or "near" off-the-shelf) software components
and tools of various kinds (both good and bad).
No implementor of a software system can ignore the question
of "buy/glue" vs. "build." When the answer is buy/glue,
the notion of "linguistic continuity" is probably at too low a level
to focus. The issues are more at the level of "architectural consistency"
and in finding the best-of-breed components and tools which will
enable the timely construction of a quality system. When operating
at this level, using Ada for glue may be a great idea, but it
is not something for which a mandate was felt to be justified, as the
bulk of the "value" of the system is in the underlying architecture and
the underlying component/tool technologies.
> [log in to unmask]
> AdaWorks Software Engineering
> Suite 30
> 2555 Park Boulevard
> Palo Alto, CA 94306
> (415) 328-1815
> FAX 328-1112
-Tucker Taft [log in to unmask]