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