The trouble with Ada... (60 lines)

The trouble with Ada... (60 lines)

[paul goffin]

The trouble with Ada is that it exposes poor software engineers
and project managers.

Ok.  What do I mean?

I've been in the software engineering business for about 10 years
now.  I've seen, and worked on, some very good software systems.
I've seen, and worked on, some awful ones.

It's been my experience that the difference between a good and
bad software system has a lot to do with the quality of the
software project management.

Most good systems gave a lot of thought to the system design,
and then a lot of management effort was expended to keep
that design on track.  Usually the best method to keep
the project "good" was to make the "good" way the easy way;
that is make it easier for programmers to use "good" practice
than to just "hack and slay".

Most bad systems had almost no thought about design at all,
and even where there was such thought, the project manager
quickly lost control.

Ok, so we all knew all that, and what did I mean about Ada
exposing poor software engineers and managers?

I've found that if you ask someone to do something they can't do
or don't want to do, then instead of telling you they can't do it,
they _pretend_ to be getting on with it.  Most of the time, they
actually aren't pretending (that's what makes it so hard to spot),
they actually are working very hard, and even believe that they are
doing good work.

Thing is what they tend to be doing is coding and testing the "easy
bit" of the job.  In fact they will, given the chance, use all the project
time doing the bit they knew how to do; they won't address the
"difficult bit" at all.

Now when you use 'C' as the coding language, it's very easy
to give the illusion of actually doing useful work, when in
fact all you are doing is tracking down silly coding errors.

In Ada, those coding errors are quickly exposed by the compiler.
Worse, it's actually difficult when using Ada to write any code
at all if you don't have a very good idea about the total
design.  That means you have to address the "difficult bit" first.
(I think that's what Ada was all about!)

So, what happens?  Well, instead of addressing the problem, producing
the design and finally coding (in Ada), the programmers sit around
and look for ways not to use Ada.  As their managers don't see
the real problem, they are soon convinced that it's all Adas fault
and they start looking for waivers.

Paul
-- 
+-------------+-------------------------------------------------------+
+ Paul Goffin +  Crosfield Electronics Ltd. U.K.  +44 442 230000x3357 +
+             +  Opinions expressed are mine! (Yours for a small fee) +
+-------------+-------------------------------------------------------+

Re: The trouble with Ada... (60 lines)

[dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.co]

In <15467@suns4.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writes:

>The trouble with Ada is that it exposes poor software engineers
>and project managers.

>Ok.  What do I mean?

>I've been in the software engineering business for about 10 years
>now.  I've seen, and worked on, some very good software systems.
>I've seen, and worked on, some awful ones.

>It's been my experience that the difference between a good and
>bad software system has a lot to do with the quality of the
>software project management.

>Most good systems gave a lot of thought to the system design,
>and then a lot of management effort was expended to keep
>that design on track.  Usually the best method to keep
>the project "good" was to make the "good" way the easy way;
>that is make it easier for programmers to use "good" practice
>than to just "hack and slay".

>Most bad systems had almost no thought about design at all,
>and even where there was such thought, the project manager
>quickly lost control.

>Ok, so we all knew all that, and what did I mean about Ada
>exposing poor software engineers and managers?

>I've found that if you ask someone to do something they can't do
>or don't want to do, then instead of telling you they can't do it,
>they _pretend_ to be getting on with it.  Most of the time, they
>actually aren't pretending (that's what makes it so hard to spot),
>they actually are working very hard, and even believe that they are
>doing good work.

>Thing is what they tend to be doing is coding and testing the "easy
>bit" of the job.  In fact they will, given the chance, use all the project
>time doing the bit they knew how to do; they won't address the
>"difficult bit" at all.

Other than the first paragraph, I can agree with you up to this point. 

>Now when you use 'C' as the coding language, it's very easy
>to give the illusion of actually doing useful work, when in
>fact all you are doing is tracking down silly coding errors.

And now we get down to the stupid, language bashing part.  Look.  If
you're so upset that C is orders of magnitude more popular and
accepted in the general computing community than is Ada, that's fine.
But don't try to dress your prejudices up in technical clothes and
submit them as 'proof'.  You can 'hack' in any language, and bad code
can be written in every language.  Convincing yourself that Ada is
some kind of 'magic bullet' is a good way to produce some bad code. 

>In Ada, those coding errors are quickly exposed by the compiler.
>Worse, it's actually difficult when using Ada to write any code
>at all if you don't have a very good idea about the total
>design.  That means you have to address the "difficult bit" first.
>(I think that's what Ada was all about!)

Not at all.  You do it wrong just the way you would do it wrong in C;
divide the problem into sub-parts and then do the easy ones.

>So, what happens?  Well, instead of addressing the problem, producing
>the design and finally coding (in Ada), the programmers sit around
>and look for ways not to use Ada.  As their managers don't see
>the real problem, they are soon convinced that it's all Adas fault
>and they start looking for waivers.

Yeah, sure they do.  You know, for something that can't possibly work,
there sure seems to be an awful lot more functioning software written
in C than in Ada.

>Paul
>-- 
>+-------------+-------------------------------------------------------+
>+ Paul Goffin +  Crosfield Electronics Ltd. U.K.  +44 442 230000x3357 +
>+             +  Opinions expressed are mine! (Yours for a small fee) +
>+-------------+-------------------------------------------------------+

I think the fee I paid for your opinion in this case is just about
what it was worth.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: The trouble with Ada... (60 lines)

[Tony Wen Hsun Lai]

In article <1992Sep22.172353.23907@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:
>In <15467@suns4.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writes:
[stuff deleted]
>You can 'hack' in any language, and bad code
>can be written in every language.  Convincing yourself that Ada is
>some kind of 'magic bullet' is a good way to produce some bad code. 
>
>>In Ada, those coding errors are quickly exposed by the compiler.
>>Worse, it's actually difficult when using Ada to write any code
>>at all if you don't have a very good idea about the total
>>design.  That means you have to address the "difficult bit" first.
>>(I think that's what Ada was all about!)
>
>Not at all.  You do it wrong just the way you would do it wrong in C;
>divide the problem into sub-parts and then do the easy ones.

But in practice, different languages often suggest different styles or
different approaches to solving problems, so the types of bad code that are
prevalent will be different.  Also, different language communities have
different mentalities; the "superhacker" mentality is presumably harder
to find among Ada programmers than C programmers.  A language isn't
completely responsible for the programmers' mentalities, but it does have
an effect.

>"Insisting on perfect safety is for people who don't have the balls to live
> in the real world."   -- Mary Shafer, NASA Ames Dryden

Hm.  Do you also mention this to C++ programmers who criticize dynamically
typed languages?  :)

Tony Lai

Re: The trouble with Ada... (60 lines)

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!mccall]

In <92Sep22.205921edt.47893@neat.cs.toronto.edu> tlai@cs.toronto.edu (Tony Wen 
Hsun Lai) writes:

>In article <1992Sep22.172353.23907@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com
 (fred j mccall 575-3539) writes:
>>In <15467@suns4.crosfield.co.uk> pdg@crosfield.co.uk (paul goffin) writes:
>[stuff deleted]
>>You can 'hack' in any language, and bad code
>>can be written in every language.  Convincing yourself that Ada is
>>some kind of 'magic bullet' is a good way to produce some bad code. 
>>
>>>In Ada, those coding errors are quickly exposed by the compiler.
>>>Worse, it's actually difficult when using Ada to write any code
>>>at all if you don't have a very good idea about the total
>>>design.  That means you have to address the "difficult bit" first.
>>>(I think that's what Ada was all about!)
>>
>>Not at all.  You do it wrong just the way you would do it wrong in C;
>>divide the problem into sub-parts and then do the easy ones.

>But in practice, different languages often suggest different styles or
>different approaches to solving problems, so the types of bad code that are
>prevalent will be different.  Also, different language communities have
>different mentalities; the "superhacker" mentality is presumably harder
>to find among Ada programmers than C programmers.  A language isn't
>completely responsible for the programmers' mentalities, but it does have
>an effect.

Are you suggesting that you let language impact your design?  How
Politically Incorrect of you!  :-)

Anyway, I don't think the 'superhacker' mentality is any less
prevalent in Ada -- it is just justified differently.  After all, how
many people have you heard assert that SIMPLY BECAUSE THEY ARE USING
ADA they will not have this or that error?  Sounds like an
unreaasonable faith in a 'magic bullet' to me; just another wya to
justify the 'superhacker' syndrome.

Yes, language will somewhat impact your approach to a problem, but
this should happen only insofar as taking into account SHORTCOMINGS of
the language is an impact.  This is another one of those
mythology-breaking things.  The 'popular wisdom' says that
requirements, design, and implementation should be separate (this is
changing as people realize that making software is done best as an
iterative process, where the stages overlap and are periodically
revisited).  However, it does you little good to come up with a great
design that meets the requirements in theory, but which is so
difficult (or impossible) to implement in the language you have to use
that you would have been better off doing things some (theoretically)
less-optimal way.

The point, of course, is that good code is possible in all languages.
Likewise bad code.  Insisting that a LANGUAGE is better without
specifying WHO and WHAT is to be produced is simply a semantically
null statement.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: The trouble with Ada... (60 lines)

[Robert I. Eachus]

In article <1992Sep24.150801.20492@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com 
(fred j mccall 575-3539) writes:

   Anyway, I don't think the 'superhacker' mentality is any less
   prevalent in Ada -- it is just justified differently.  After all,
   how many people have you heard assert that SIMPLY BECAUSE THEY ARE
   USING ADA they will not have this or that error?  Sounds like an
   unreaasonable faith in a 'magic bullet' to me; just another way to
   justify the 'superhacker' syndrome.

   Yes, language will somewhat impact your approach to a problem, but
   this should happen only insofar as taking into account SHORTCOMINGS of
   the language is an impact.  This is another one of those
   mythology-breaking things...

   Sorry Fred, but anyone who has done much Ada development knows
that developing in Ada IS different.  Back in 1983-1985 the Greek
chorus at AdaTEC (later SIGAda) meetings was that "Ada is not just
another programming language."  Learning to program in Ada meant
learning software engineering.

   A few years later, many people had discovered that development in
Ada meant something like 60% design, 20% code, 10% integration and test.
Much different from the old 40% design, 50% code, 90% integration and
test.  It is now becoming apparent WHY this is, which is why I started
preaching to the converted.  (Anyone who has seen the magic of the
integration phase of a large Ada project knows that things are
different.  Anyone who hasn't doesn't believe it.)

   My experience has been that in over a million lines of Ada code,
ALL of the problems I have encountered in system integration involved
script files and pathnames.  All of the parameter mismatches and name
conflicts were long gone by then, as well as most of the bugs.  One
system had one bug report in the first six months after it was
released--an error message was misspelled, most others had none.
(This of course does not include internal and beta testing.)

   Why does it work out this way?  Because it is very easy to express
ANY workable system design in Ada.  So if you can't express the
design, you know you are in trouble.  And you find out early.  Of
course, many times the design is expressable in Ada but won't work.  I
have always found it fairly easy to reconfigure the design in these
cases, with even major reorganizations requiring only a couple of
days.  Minor fixes like add another parameter to an interface or
another field to a record usually takes less than an hour, including
recompiles.
--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...