From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e29c511c2b08561c X-Google-Attributes: gid103376,public From: pp000166@interramp.com (Robert Munck) Subject: Re: Is the "Ada mandate" being reconsidered? Date: 1996/05/17 Message-ID: <319bf511.185397360@news.interramp.com>#1/1 X-Deja-AN: 155271845 references: <3197f594.11851222@news.interramp.com> organization: PSI Public Usenet Link reply-to: munck@acm.org newsgroups: comp.lang.ada Date: 1996-05-17T00:00:00+00:00 List-Id: On Tue, 14 May 1996 17:53:29 GMT, stt@henning.camb.inmet.com (Tucker Taft) wrote: >Admittedly, not all of us have done DoD software development, >but pretty much all of us have been in the trenches developing >software, But that's the difference that's important. There is a huge gap between developing s/w in a commercial, university, or vendor environment and doing so as a bare-bones DoD contractor on a production application project. For one thing, I'll bet you that the people you've worked with at Intermetrics, and that I worked with at SofTech, were paid twice as much and were ten times as good as equivalent programmers for big aerospace contractors. DoD projects force contractors to use the cheapest people possible. Other differences include the tremendous rate of requirements changes, with your own company's management and marketing encouraging it and doing nothing to protect you from it. Also, the institutional barriers, government and contractor alike, that make it absolutely impossible to do any kind of real s/w reuse, rapid prototyping, fads like cleanroom or O-O. The schedules written with no connection to reality or possibility. Etc. etc. These things have all had a lot more to do with the success or failure of Ada over the last 15 years than anything like language features, development tools, or lack of commercial success. >and are quite familiar with the sorry state >of many "off-the-shelf" software products and components. Heck, the committee's own charter makes COTS an untouchable: "While commercial off-the-shelf (COTS) software is considered the first choice for military systems, ..." After all, some of the people who developed this policy are still in place and well short of retirement. >In any case, at this point the Ada community might want to focus >on providing constructive, well documented, input to the committee. Like what? What kind of things would you like to see? I'm completely at a loss. What kind of input could there be, other than anecdotes? Are you guys going to have access to the kinds of financial data, project post-mortems, long-term maintenance costs, successful and failed projects, etc. that would make a quantative, bottom-line decision possible? Bob Munck@acm.org