Ada ad in Embedded Systems Programming stinks 
Author Message
 Ada ad in Embedded Systems Programming stinks


Quote:
> PS: We do NOT have an Ada mandate from our DoD in Australia, but on
> some defence projects in the past Ada has been specified. This practice
> is now almost extinct.

G'day Brendan,
Do you mean that the Collins submarine project, the ANZAC frigate project
and the JOHRN project aren't being done in Ada?
Bob W. (-:


Mon, 31 Mar 1997 18:51:47 GMT  
 Ada ad in Embedded Systems Programming stinks


Quote:

>> PS: We do NOT have an Ada mandate from our DoD in Australia, but on
>> some defence projects in the past Ada has been specified. This practice
>> is now almost extinct.

>G'day Brendan,
>Do you mean that the Collins submarine project, the ANZAC frigate project
>and the JOHRN project aren't being done in Ada?
>Bob W. (-:

G'day to you too, Bob,

No, that is not what I meant. The three programs that you mention were all
contracted between 3 and 7 years ago! Some of these are in fact the projects
to which I was referring where Ada has been mandated in the past. Note that
in these cases, Ada was in fact mandated by the project office concerned,
specifically for the one project only.

My original statement that "We do NOT have an Ada mandate from our DoD in
Australia" is correct.

Note also that about 9 out of 10 RFT's coming out of the Australian DoD in
the past few years DO NOT mandate Ada. The typical statement is that "A high
level language, such as Ada, C, or C++ should be used". There is also
usually a big emphasis on the use of COTS, (Commercial Off The Shelf),
software in any proposed solution.

It is also worth noting that of three Ada projects you mentioned, I know for
a fact that at least two of these are in SERIOUS trouble, facing serious
architectual/design problems and the resulting cost and schedule slip (like 3+
years late!!).

----------------------------------------------------------------------
--
Brendan Walker          | The opinions expressed above are obviously
IASSF Project,          | the ramblings of a troubled mind, and
EASAMS (Australia)      | therefore not those of my employer.



Mon, 14 Apr 1997 13:45:39 GMT  
 Ada ad in Embedded Systems Programming stinks

[...]

: It is also worth noting that of three Ada projects you mentioned, I know for
: a fact that at least two of these are in SERIOUS trouble, facing serious
: architectual/design problems and the resulting cost and schedule slip (like 3+
: years late!!).

My brother remember a local computer company that made PDP (is that?)
clones getting the contract to supply computers for the Submarines.
He did work experience there and remembers tha machines ranged from
full-tower boxes to machines bigger than large filing cabinets, that he
had to climb on top of to get access to some components.

This was about 10 years ago.  I'm not suprised that folks are having
a hard time getting programs to work well on 10 year old computers.
I'd be suprised if compiler vendors supported architectures that old.

- Bill



Wed, 16 Apr 1997 00:17:37 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:



> >> PS: We do NOT have an Ada mandate from our DoD in Australia, but on
> >> some defence projects in the past Ada has been specified. This practice
> >> is now almost extinct.

> >G'day Brendan,
> >Do you mean that the Collins submarine project, the ANZAC frigate project
> >and the JOHRN project aren't being done in Ada?
> >Bob W. (-:

> G'day to you too, Bob,

> No, that is not what I meant. The three programs that you mention were all
> contracted between 3 and 7 years ago! Some of these are in fact the projects
> to which I was referring where Ada has been mandated in the past. Note that
> in these cases, Ada was in fact mandated by the project office concerned,
> specifically for the one project only.

> My original statement that "We do NOT have an Ada mandate from our DoD in
> Australia" is correct.

This was not what I was opposing. This is {*filter*}y obvious! (-: (not to mention
a source of satisfaction for many in the Ada world that Oz uses Ada because we
want to, and not because we *have* to! Dare I say the *M* word. (-: )

Quote:
> Note also that about 9 out of 10 RFT's coming out of the Australian DoD in
> the past few years DO NOT mandate Ada. The typical statement is that "A high
> level language, such as Ada, C, or C++ should be used". There is also
> usually a big emphasis on the use of COTS, (Commercial Off The Shelf),
> software in any proposed solution.

Once again this is similar to what the DoD's policy is. "If there is something
out there that does what we want, buy that! Don't go out and pay for something
to be custom built. Even if it is going to be done in Ada!" I thought that ongoi
ng
support for the use of Ada was quite forthcoming in Oz? Given the maintainabilit
y
advantages of Ada (when correctly used in the first place), Defence prefers that
Ada be used as I understand it. Did the original RFT's for the above projects sa
y
that *only* Ada was to be used? Isn't the JORN project still being moved from
fortran to Ada?

What about your F111 work? Was the RFT written exclusively specifying Ada? Did
you have to justify your choice of C++ (if my memory serves me correctly) to the
customer (I guess the RAAF).

Quote:
> It is also worth noting that of three Ada projects you mentioned, I know for
> a fact that at least two of these are in SERIOUS trouble, facing serious
> architectual/design problems and the resulting cost and schedule slip (like 3+
> years late!!).

Which two? Is this a "from what I've read in the newspapers" type statement or a
true assessment?

Anyone out there from Telstar care to comment on JORN?

Anyone from CSA care to comment on the sub project? Andy Lees, are you still at
CSA? Can you comment here?

I assume that these two are the ones you mean. (Or if it is the ANZAC frigate
project, can anyone from CSA comment on that?)

We've had one Ada flop where everything was thrown out (Queensland TAB) let's
hope that these aren't aswell.

  Bob Wells               "Si hoc signum legere potes, operis boni in rebus



Tue, 15 Apr 1997 19:55:46 GMT  
 Ada ad in Embedded Systems Programming stinks

[snip]

Quote:
>It is also worth noting that of three Ada projects you mentioned, I know for
>a fact that at least two of these are in SERIOUS trouble, facing serious
>architectual/design problems and the resulting cost and schedule slip (like 3+
>years late!!).

Hmm,

I suspect that I should not really respond to this, but the implication here
(that Ada is involved in any problems these projects may have ) is simply
too wrong to leave alone.

I am aware of all of these projects, having been involved in one for seven
years, having technically auditted one other, and having close contacts
in the third.

Where there have been problems, the root causes have been in the management
domain rather than the technical.  This is so on both of the projects that
have had some difficulties.  On the project that has not had difficulties,
the same applies:  the reason for its success has been consistently
excellent management.

In my direct experience (and despite my own doubts along the way) Ada has been
a good implementation language for large projects.  What needs to be understood
is that no language can make up for unresolved management issues.  When
management issues start to become solved, projects start to make real progress.

The design of the Ada language simplifies the management of the software
production process considerably.

When used well, the visibility
structures of the language enable very rapid understanding to be obtained
of code to which one has had no previous exposure.  My role frequently
involves system troubleshooting so I value this aspect of the language
highly.  I know of no other language in large scale use that would be
as helpful.  (Yes, I have spent many years developing software in 'C').

I see Ada as providing significant benefits in the development of large
systems.  Having said this, I can see that we are not yet taking proper
advantage of all that can be gained from the language, with better
design processes and attendent reduction in rework having particular
scope for useful productivity improvements.

Quote:
>----------------------------------------------------------------------
>--
>Brendan Walker              | The opinions expressed above are obviously
>IASSF Project,              | the ramblings of a troubled mind, and
>EASAMS (Australia)  | therefore not those of my employer.

Andrew Lees.




Thu, 17 Apr 1997 09:14:14 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:

>[...]

>: It is also worth noting that of three Ada projects you mentioned, I know for
>: a fact that at least two of these are in SERIOUS trouble, facing serious
>: architectual/design problems and the resulting cost and schedule slip (like 3+
>: years late!!).

>My brother remember a local computer company that made PDP (is that?)
>clones getting the contract to supply computers for the Submarines.
>He did work experience there and remembers tha machines ranged from
>full-tower boxes to machines bigger than large filing cabinets, that he
>had to climb on top of to get access to some components.

>This was about 10 years ago.  I'm not suprised that folks are having
>a hard time getting programs to work well on 10 year old computers.
>I'd be suprised if compiler vendors supported architectures that old.

>- Bill

--



Fri, 18 Apr 1997 04:17:33 GMT  
 Ada ad in Embedded Systems Programming stinks
Quote:


>[snip]

>>It is also worth noting that of three Ada projects you mentioned, I know for
>>a fact that at least two of these are in SERIOUS trouble, facing serious
>>architectual/design problems and the resulting cost and schedule slip (like 3+
>>years late!!).

>Hmm,

>I suspect that I should not really respond to this, but the implication here
Probably right!
>(that Ada is involved in any problems these projects may have ) is simply
>too wrong to leave alone.

>I am aware of all of these projects, having been involved in one for seven
>years, having technically auditted one other, and having close contacts
>in the third.

>Where there have been problems, the root causes have been in the management
>domain rather than the technical.  This is so on both of the projects that

Well, yes and no. Ada 83 provides a way to get the address of a procedure,
but doen't provide a way to _call_ a procedure using its address. Management
decides that the project is to be done in pure Ada, and forbids use of
assembly language to call a procedure using its address.
Quote:
>have had some difficulties.  On the project that has not had difficulties,
>the same applies:  the reason for its success has been consistently
>excellent management.

>In my direct experience (and despite my own doubts along the way) Ada has been
>a good implementation language for large projects.  What needs to be understood
>is that no language can make up for unresolved management issues.  When
>management issues start to become solved, projects start to make real progress.

>The design of the Ada language simplifies the management of the software
>production process considerably.

>When used well, the visibility
>structures of the language enable very rapid understanding to be obtained

Are the visibility structures of Ada 83 really any better than those of C++?
Doesn't Ada 83 suffer from the lack of a structure larger than a package,
something like the new C++ namespace?
Quote:
>of code to which one has had no previous exposure.  My role frequently
>involves system troubleshooting so I value this aspect of the language
>highly.  I know of no other language in large scale use that would be
>as helpful.  (Yes, I have spent many years developing software in 'C').

>I see Ada as providing significant benefits in the development of large
>systems.  Having said this, I can see that we are not yet taking proper
>advantage of all that can be gained from the language, with better
>design processes and attendent reduction in rework having particular

Better design methods would help, but watch out for management interpreting
'reduction in rework' to mean 'iterative development is forbidden'.

Quote:
>scope for useful productivity improvements.

>>Brendan Walker

>Andrew Lees.

Chris Perrott


Thu, 17 Apr 1997 10:41:04 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:


>[...]
>: It is also worth noting that of three Ada projects you mentioned, I know for
>: a fact that at least two of these are in SERIOUS trouble, facing serious
>: architectual/design problems and the resulting cost and schedule slip (like 3+
>: years late!!).
>My brother remember a local computer company that made PDP (is that?)
>clones getting the contract to supply computers for the Submarines.
>He did work experience there and remembers tha machines ranged from
>full-tower boxes to machines bigger than large filing cabinets, that he
>had to climb on top of to get access to some components.
>This was about 10 years ago.  I'm not suprised that folks are having
>a hard time getting programs to work well on 10 year old computers.
>I'd be suprised if compiler vendors supported architectures that old.
>- Bill

Different submarines, different project, I believe.  (Previous generation).

Andy.



Fri, 18 Apr 1997 19:14:23 GMT  
 Ada ad in Embedded Systems Programming stinks

Quote:
> This was about 10 years ago.  I'm not suprised that folks are having
> a hard time getting programs to work well on 10 year old computers.
> I'd be suprised if compiler vendors supported architectures that old.

Bill,
I'm sure that these boxes must have been for the old Oberon class subs and
not the new Collins class subs.
Bob W.


Fri, 18 Apr 1997 18:33:08 GMT  
 Ada ad in Embedded Systems Programming stinks

|> I'm sure that these boxes must have been for the old Oberon class subs and
|> not the new Collins class subs.

What? Submarines programmed using Oberon classes?  (I guess that's what
they mean by "sub classes".)

--



Sat, 19 Apr 1997 01:12:33 GMT  
 Ada ad in Embedded Systems Programming stinks

|> Are the visibility structures of Ada 83 really any better than those of C++?
|> Doesn't Ada 83 suffer from the lack of a structure larger than a package,
|> something like the new C++ namespace?

Actually since Ada's packages aren't coupled with types it is a much
more flexible encapsulation mechanism than classes in C++. In Ada 83
you could put anything you wanted in a package including other packages
so it is certainly large enough. (Child packages are a better solution
IMHO).

Namespaces in C++ are being added to patch up a known defficiency
in the language and make it easier to reuse software. Fortunately
Ada 83 already had a very workable solution to namespace management.

- Robb Nebbe



Sat, 19 Apr 1997 17:45:36 GMT  
 Ada ad in Embedded Systems Programming stinks


Quote:


>|> I'm sure that these boxes must have been for the old Oberon class subs and
>|> not the new Collins class subs.

>What? Submarines programmed using Oberon classes?  (I guess that's what
>they mean by "sub classes".)

>--


 ^^^^^^^^^^^^^^^

 Now a strong contender for "Worst Pun of the Year" award.  :-)

--
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
              Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada
For all sorts of interesting Ada tidbits, run the command:   ||________________

   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-)



Sun, 20 Apr 1997 22:39:48 GMT  
 Ada ad in Embedded Systems Programming stinks


   > Where there have been problems, the root causes have been in the
   > management domain rather than the technical.  This is so on both
   > of the projects that have had some difficulties.  On the project
   > that has not had difficulties, the same applies: the reason for
   > its success has been consistently excellent management.

   > Well, yes and no. Ada 83 provides a way to get the address of a
   > procedure, but doen't provide a way to _call_ a procedure using
   > its address. Management decides that the project is to be done in
   > pure Ada, and forbids use of assembly language to call a procedure
   > using its address.

   Is it just me or did everyone spot the irony here?  Ada 83 does
provide mechanisms for calling procedures given addresses, and for
that matter for embedding assembler.  It's just that the stnadard
(correctly) points out that these things are dependent on
characteristics of the implementation .  Good management reads this as
a reason to encapsulate the dependencies in a limited part of the
code, clueless management forbids the use.

   The most ridiculous example of this was a revision request for Ada
9X where the functionality requested was already provided by
Unchecked_Conversion.  The request was of course turned down.  But the
requestor responded that Unchecked_Conversion was not a solution--his
company coding standards did not allow him to use it!

    The only good news in all this is that we have found that it is
harder for poor (or worse) management of an Ada development project to
get the project in a state where the only viable option is to cancel
it.

--

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...



Sun, 20 Apr 1997 23:35:11 GMT  
 Ada ad in Embedded Systems Programming stinks

writes:

Quote:

> [snip]
> >It is also worth noting that of three Ada projects you mentioned, I know for
> >a fact that at least two of these are in SERIOUS trouble, facing serious
> >architectual/design problems and the resulting cost and schedule slip (like 3+
> >years late!!).
> Hmm,
> I suspect that I should not really respond to this, but the implication here
> (that Ada is involved in any problems these projects may have ) is simply
> too wrong to leave alone.

I can't leave it alone, either.  Two years ago, I attended a design
review for an Ada project that was in trouble.  My observations were
published in the June 1993 issue of Ada User (reproduced below with
permission).

Last month I checked up on the project.  It has not failed (yet), but
the software contractor came close to missing a payroll, and is flirting
with bankruptcy.  The project is way over budget and hopelessly behind
schedule.  They expect to deliver software that does not meet many
of the requirements.  As predicted, Innocent Ada Gets the Blame.

            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            |                                |

            +--------------------------------+

------------------------------------------------------------
                 Reprinted from Ada User
                  Ada Language UK, Ltd.
                    with permission.
------------------------------------------------------------
                                                            1

                                                 +---------+
                                                 | Opinion |
                                                 +---------+

                Innocent Ada Gets the Blame

                       Do-While Jones

     I recently attended the software portion of a Critical
Design Review (CDR) for an important project being developed
jointly by two American armed services.  One of the parties
involved asked me to attend and give my assessment of the
project status.  It is my opinion that the project is in
trouble, and Ada will get the blame, even though it isn't
her fault.
     Unfortunately, this project is typical of so many
software development projects.  They are making the same
mistakes that are so common these days, but these mistakes
somehow remain unrecognized.  Since Ada is supposed to save
us from all our problems, she will get the blame when the
project fails.  We need to open our eyes to the real
problems and concentrate on solving them, rather than
blaming an innocent party.
     Four major problems surfaced at that CDR, but nobody
seemed to notice.  (1) The contractor and the U.S.
government are working against each other, rather than
working together.  (2) The government-imposed software
development methodology encourages the contractor to produce
a bad design.  (3) The contractor is trying to defeat Ada's
software engineering features. (4) The contractor's
configuration management system is badly flawed.
     The project in question is a real-time multi-media
system that combines a graphical display of processed data
with audio (voice) data.  The audio data is digitized,
compressed, and stored with the rest of the digital data so
that the audio will remain synchronized with the graphical
data when the event is replayed later for debriefing and
analysis.  The software is written in Ada for a Silicon
Graphics workstation running X-windows on UNIX.

Lack of Teamwork

     The attitudes of the people at the CDR quickly showed
that the project is in trouble.  This was apparent from an
"us vs. them" relationship between the government and the
contractor.  The contractor was late and defensive.  The
government was angry and distrustful.  There wasn't a team
spirit.  They weren't working together.  Each side was eager
to place the blame on the other.
     Here is an example:  This project is an improvement of
an existing system.  One of the system requirements is the
new system should have all the capability of the old system,
and then some.  The Silicon Graphics computers they are
using have audio capabilities that the old system didn't

                                                            2

have.  The old system could digitize and record audio data,
but it had no way to play it back.  It needed an external
audio amplification system.  Since it could not reproduce
the audio data, it had a diagnostic feature that displayed
audio data as hexadecimal values that scrolled off the
screen faster than anyone could possibly read.  Even if you
could read them, there isn't a person alive who could tell
what it sounded like.  It was a totally useless feature.
     The contractor wasted time and money by designing a
visual hexadecimal dump of audio data for the Silicon
Graphics system.  At the CDR, the contractor reported that
they had done this, even though they knew the feature was
stupid and worthless.  Although they didn't come right out
and say so, the tone of voice and body language said, "We
knew that if we didn't implement this feature, the
government would write us up as being deficient and penalize
us for it, so we beat you to the punch by wasting your time
and money and now there's nothing you can do about it
because our lawyers say there is an iron-clad requirement
for it.  If you want us to take it out, it will cost you
even more money.  Ha, ha, ha!"
     The government has a long history of this kind of
relationship with contractors.  It is a direct result of the
laws governing federal procurement.  Corrupt people believe
everyone else is as corrupt as they are.  Lawmakers see
trust and cooperation as unmistakable evidence of some
under-the-table kickbacks or other unfair labor practice.
Therefore, they have made it illegal to have any
relationship with a contractor that is based on trust or
cooperation.  Contracts must always be awarded to the
contractor who underbids the most.  Actual cost of the
contract is determined through litigation concurrent with
project development.

Methodology Maladies

     MIL-STD-2167A describes "the one true way for good
software development."  Unfortunately, that method is badly
flawed, and problems experienced by a software project are
generally proportional to the extent of its use.  On this
particular project, the government is strictly enforcing
2167A, with the usual disastrous results.
     Fundamental to 2167A is the "waterfall model" of
development.  This model requires that there be a Critical
Design Review at the end of the design development phase.
The project must obtain approval at this review before the
implementation phase (i.e., writing code) may begin.  The
primary document reviewed at a CDR is the Software Detailed
Design (SDD) document.  In theory, this SDD contains all the
pertinent design information needed to make an intelligent
decision whether the project is on track or not.  The
approved SDD theoretically serves as the foundation for the
coding effort.

                                                            3

     Near the end of the presentation of the SDD at the CDR,
a man sitting next to me whispered that he had just figured
out what was wrong.  Everyone was trying to guess what the
user's manual would be like from the description of the
software configuration items contained in the SDD.  He
thought that there would be much less argument and much more
understanding if they simply wrote the user's manual first
and presented it at the CDR instead.  He was on the right
track.  Most people were trying to guess what the user's
manual would be like, but the rest of the people were trying
to guess what the Ada code would be like.  Nobody really
cared about the SDD.  They were just trying to use the SDD
as an awkward, indirect, unreliable way to find out what
they really wanted to know.  A preliminary user's manual and
some carefully chosen code fragments from a prototype design
would have told them what they really wanted to know.
     The questions that the government needed to ask the
contractor were:  How is it going to work?  How are you
doing it?  How much have you done?  When do you think it
will be finished?  What is the biggest problem facing you at
the moment?  What do you need us to do to help you?  Do you
still think it will cost what we estimated it would?
Unfortunately, 2167A requires that contractors must cloak
their methods, intentions, and progress behind a vague and
ambiguous detailed design specification, and that they must
present these specters and shadows using smoke and mirrors
at a CDR.
     Everything I really needed to know, I learned in the
hallway.  In the hallway, the contractor was willing to
admit that they already had written code and were testing
it.  In the hall, the contractor could tell the truth about
what was really going on.  Only on rare occasions during the
formal presentations did the speakers slip and answer
questions in a careless way that betrayed that the SDD
hadn't quite kept up with their real design.
     The format of the SDD makes it difficult to clearly
describe an existing design.  Occasionally people in the
audience asked about things that weren't shown in the
detailed design document.  The contractor's response was
always that their design really satisfies the requirement,
but the SDD just doesn't show it.
     For example, the X-windows services don't appear
anywhere in the design specifications, yet it is X-windows
that holds the whole program together.  More than half of
the code is X-windows and UNIX services, and they aren't
mentioned at all in the SDD!  One could argue that X-windows
is an ...

read more »



Wed, 23 Apr 1997 05:46:03 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Ada ad in Embedded Systems Programming stinks

2. Ada in Embedded Systems Programming.

3. Ada vanishes from Embedded Systems Programming

4. Ada is almost useless in embedded systems

5. CNF: Embedded Systems Club and Ada UK User Group Autumn Conference

6. Real-time embedded systems - Ada resources

7. Ada in embedded systems?

8. Why no Ada at Embedded Systems Conference?

9. Ada for embedded system specification - tools ?

10. Internet Resource Lists - Ada, Embedded Systems - Pointer

11. Ada is almost useless in embedded systems

12. Ada is almost useless in embedded systems

 

 
Powered by phpBB® Forum Software