On Sun, 3 Nov 1996, Tucker Taft wrote:
> If you read the (full) report carefully, it is not a question of DoD turning
> it's back on Ada in the logistics (when non-critical) and financial systems
> market. It is a question of the DoD recognizing that in these fields, it may
> be better for the DoD to follow rather than lead, for they are a relatively
> small part of the market. The report encourages projects to consider
> Ada for custom 3GL development in these domains, and requires
> that projects go through a Software Engineering review process as
> part of making such a decision, but it drops the assertion that
> doing custom 3GL development exclusively in Ada in these domains is a
> "no-brainer." If Ada is going to be chosen for development in these domains,
> it needs to be actively chosen, rather than being used by default.
Encouraging projects to consider Ada is an interesting notion. It isn't
likely to work given all the bad press Ada has had over the past ten
or more years. You, Tucker, have done a fine piece of work in bringing
Ada up-to-date, and I think the Ada policy should be extended so the
minsconceptions regarding the language can be rectified through its use
on a wider range of successful projects. A lot of DoD managers are
breathing a sigh of relief knowing they can now go about their software
development process doing any damn thing they want. Certainly, that is
what they have done for years, but rather than say, "We don't know how
to manage a software policy, so let's throw it to the wolves," it would
have been better to develop a program for improving management.
>
> Furthermore, in these domains, the development problem is often dominated
> by the challenges of using Commercial Off The Shelf (COTS) solutions
> wisely. Custom 3GL development should be minimized where satisfactory
> cost-effective solutions can be built by integrating COTS products.
I have no problem with using COTS. However, COTS, when building
software is not well-understood. I see DoD sites which use
so-called COTS development tools that result in so much procedural
code (dBASE, FOXPRO, CLIPPER stuff) that no reasonable person could
still consider it COTS. But it is determined to be COTS because the
product used for the development is "off-the-shelf."
> On the other hand, in the DoD-dominated, high-assurance, real-time,
> "warfighting" domain, using Ada has compelling advantages, the DoD is
> the leader and should be more than willing to blaze a trail if
> necessary.
Guess what? This new policy will be followed more for its loopholes
than for its recommendations. What will be "warfighting?" And this
opens the door for people who are attempting to abandon Ada to even
further erode its influence in DoD systems.
> This all seems to presume that if Ada has to be chosen rather than being
> mandated in these domains, that it won't be chosen. Given your experience
> with your readers, that seems unnecessarily pessimistic, and a bit
> hypocritical.
I respond first to your use of the emotionally-charged pejorative,
"hypocritical." I realize you may feel some investment in the report
I am criticizing, but I am not attacking you or the other authors. I
am questioning the report. I respect you and all the other people
who were on this committee, but I do disagree with the conclusions
in the fragment I have read.
The readers to who you refer are reacting favorably to the things
written by me and others regarding the new Ada standard. However,
Ada does not have the dollars behind it that an overhyped newcomer
such as Java has. To abandon the Ada policy now is premature. In
the next couple of years, it would make sense to revisit the policy,
but Ada 95 is not gain the foothold it needs in the commercial sector
if it is perceived as having been abandoned by the DoD. And that is
exactly how it will be perceived in the press at large.
Also, I have always felt the word "mandate" was inappropriate. It was
used so heavily by Greg that everyone assumed it was a mandate. Rather,
from my point-of-view, it has been a DoD policy, much like any other
DoD policy. The main difference between DoD software policy and other
DoD policies is that this one was badly managed from the very start.
So now, instead of managing better, we simply abandon what was a
correct policy. I see that as the wrong direction to proceed,
especially given the quality of the new Ada 95 standard.
> Many people, including Greg et al, have been calling on the DoD to drop
> a mandate that isn't consistenly enforced, and let Ada stand or fall on
> its own merits. The committee felt that the mandate was not being
> enforced consistently in these domains, and furthermore, there were
> enough other considerations in building systems in these domains that
> mandating Ada was being overly simplistic. More important is to push
> people toward a "product-line", component-oriented mentality, and push
> them away from building DoD-unique, "stove-pipe," stand-alone solutions.
> It seems a misdirection of energy to mandate a particular 3GL in a domain
> where you believe that doing custom DoD-unique development in a 3GL is often
> the wrong solution, and that figuring out how to build on commercial
> investments is more important.
It was not overly simplistic to have a single-language software policy.
I repeat my earlier comment. If the DoD could not manage its Ada
policy, a single-language policy, how in the world will it manage a
multi-language policy? I disagree with the conclusions of the report.
What I see on the horizon is a software mess of gigantic proportions
as we let local managers, contractors, commanders, and programmers
go any direction they want. We will sacrifice portability. We will
sacrifice longevity of the code. We will sacrifice manageability
of the process. Most of all, we will sacrifice quality.
When speaking of Hamlet's madness, we hear the phrase, "T'is pity,
t'is true. T'is true, t'is pity." I fear for the result of this
change in policy. T'is pity.
Richard
Richard Riehle
[log in to unmask]
AdaWorks Software Engineering
Suite 30
2555 Park Boulevard
Palo Alto, CA 94306
(415) 328-1815
FAX 328-1112
|