Re: An observation of Ada (may offend)

[l107353@cliffy.lfwc.lockheed.com (Garlington KE)]

Robert I. Eachus (eachus@spectre.mitre.org) wrote:
: In article <3l9dh4$8p9@butch.lmsc.lockheed.com> l107353@cliffy.lfwc.lockheed.com (Garlington KE) writes:

:  > I actually have this wacky idea that we might be able to start
:  > reusing packages from project to project without modification, in
:  > which case I may want to add new child packages well after FQT. I
:  > wouldn't call it a "kludge" -- just an ability to add new features
:  > without having to rewrite half of the package every time I want to
:  > change the available features!

:    First read what I wrote.  I can imagine cases where such a change
: would be appropriate, especially during development and I said that.

I did. You said, "after integration, there's no purpose in adding this."
What if there is a follow-on project after integration? This would be
"after integration."

: But I still believe that adding a child unit
: during integration is likely to be a kludge.

Unless, of course, new requirements were received during integration, such
as a contract change proposal with a quick turnaround. Or a quick-turn
change requested by the flight test team.

:    Now you just voluteered for the maintenance job, and it is hard to
: get good maintainers, wonderful.

I didn't volunteer for the maintenance job -- quite the opposite (see below).
I volunteered to build our software in such a way that we can leverage off
of it for future programs. Isn't that what programming by extension is
supposed to do for us?

:  When you go to add your new child
: unit, how do you know that it is not replacing another child of the
: same name, which you were unaware of?

The same way I know that I am not adding a package body for a spec which
already has a package body, or should not have a package body -- I have a CM
system.

Again, if you want to use this pragma, be my guest. I wouldn't say that
it would be widely used in the safety-critical field, as was originally
stated, because safety-critical software (like other kinds of software)
has tools and processes to control changes to our software.

  I, and many others, like the
: documentation you need to be in the logical place--in the source.

We, on the other hand, work with the eventual maintainers, who tell us that
they want program structure to be documented in a clean, summary form a la
ADARTS -- not by crunching through the source.

:  > If the maintainer has no tools or documentation (in our case, he has both),
:  > this issue is the least of his problems.

:     As anyone who has done software maintenance in the "real world"
: can tell you, no tools and no (trustworthy) documenation is standard
: practice outside the safety critical fields.  If they had good
: documentation, they wouldn't have had to call you.

The maintainers for F-22 software get the same tools we use (safety critical
and otherwise) along with the data. It's required by our contract.

And no, we don't expect them to call us. We plan for organic support. We
do, however, expect to bid (and hopefully win) new programs. We would like
to use the software from the last program on these new programs. Maybe even
without modifying it.

For that matter, in another life, I did software maintenance of COBOL (eeek!)
for a chemical company. We had tools and documentation. This may not be
true everywhere, but I at least _thought_ I was in the real world. I got
paid real money, at least :)

--------------------------------------------------------------------
Ken Garlington                  GarlingtonKE@lfwc.lockheed.com
F-22 Computer Resources         Lockheed Fort Worth Co.

If LFWC or the F-22 program has any opinions, they aren't telling me.