Re: The future of Ada

[Marin David Condic <condicma@bogon.pwfl.com>]

Larry Kilgallen wrote:
> 
> In article <7c7coa$nvt$4@plug.news.pipex.net>, "Nick Roberts" <Nick.Roberts@dial.pipex.com> writes:
> 
> > I emphasise the "is not possible" because I know well that a manager will
> > not be convinced in the slightest by "is not the best way" or the like, but
> > will be convinced by an absolute "it WILL not work".  Whether this is
> > actually strictly true or not is immaterial (and you must not show it).
> 
> Depending on your organization, an equivalently strong statement to
> "it WILL not work" is "it WILL not be delivered on time".
> 
Shooting schedules is probably one of the most persuasive arguments. The
case for this is easy to make. Historically, C/C++ spends much more time
in integration and debugging because of the unsafe constructs and lack
of compile time checks. What is worse is that you can document
significantly higher numbers of errors escaping into the field -
something that could easily bankrupt a company when the warranty costs
skyrocket. Software bugs found in the field once just about put Pitney
Bowes out of business. ("If you code it in C++ you're putting the entire
business at risk!!!" :-)

There are any number of reports on this. One of my favorites was a study
done at Lucent Technologies on the nature of the bugs discovered in
their large applications. (Wish I still had the URL...) We went through
the study informally here to see if we could gain insight into our own
bugs. (We have amazingly few, and I have metrics which show it steadily
declining since the adoption of Ada & some other tools.) The conclusion
we came to was that the overwhelming number of bug types found in
Lucent's software _could not happen_ in Ada because of compile time
checks. Lucent opted for various programmer training and code review
options to eliminate the common errors. They naturally only _reduce_ the
errors in a very costly & time consuming manner. It's always cheaper to
let the compiler find problems than to try to inspect the problems out
of the system after the fact.

Actually, I'm pretty amazed that someone would look at a system that is
near complete and decide to go back to square one & re-code it in a new
language for fear that one day there won't be any programmers who can
maintain the system. Re-coding the system in a new language is always
something that you can stall off until it becomes essential - which may
never happen. So you for sure spend the money today rather than maybe
never spend it. Spending it ten years from now is much cheaper because
of the time value of money. Pretty bone-headed, if you ask me. ;-)

-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

    "Software engineers are, in many ways, similar to normal people"

        --  Scott Adams