Working with incompetent adaists / unsafe typing war story

Working with incompetent adaists / unsafe typing war story

[Anonymous Coward]

I'd like to start with a war story:

<war story>

  Despite the lack of coding standard, Mr. Safety wrote a well
  constructed package that uses private types, then wrote some packages
  that use those types.  After these packages all reach a mature and
  refined (and tested) state, another developer (Mr. Sloppy) finds that
  they need to use Mr. Safety's package, which requires private types in
  the interface.  Mr. Sloppy refuses to work with private types.  It's
  the typical anti-strong typing mentality, where the developer refuses
  to accept anything that might limit their power.

  Mr. Safety was forced to introduce support for duplicate public
  versions of these types to accommodate Mr. Sloppy's skill limitations;
  which obviously produced a sloppy free-for-all in the work product.

  The understanding that most s/w developers seem to have is that they
  design their own interfaces for packages they create, and users of
  that ada spec only have a say in whether it meets standards and
  requirements.  I always bend to accommodate types that other
  developers require in their spec, because it's theirs.  Maybe I'm
  wrong about what I think is typical.  It was explained to me that
  interfaces are "shared" and are no more controlled by the author than
  the users of it.

</war story>

That story is just a sample of what I encounter too frequently in the
Ada workforce.  It seems a /majority/ of ada developers have no formal
Ada training, and are primarily C developers who picked up the Ada
syntax on the job.  Consequently, ada principles are lost, and much of
the ada code out there is only slightly safer than C code (but still
safer primarily because even a poor Ada developer cannot write
ambiguous code like they can in C).

I've only worked on four or so workplace ada projects.  The projects
with elaborate coding standards produced substantially better code,
but I think it was just chance that those projects also had Ada
enthusiasts who used private types, as the coding standard did nothing
to promote private typing.

Do you folks encounter this frequently?  And what's the solution?
Management can never appreciate the benefits of concepts like type
safety.  Strong typing is incorrectly viewed as "academic" and counter
to progress.

Re: Working with incompetent adaists / unsafe typing war story

[Jean-Pierre Rosen]

Anonymous Coward a �crit :
> [War story snipped]
> Do you folks encounter this frequently?  And what's the solution?
> Management can never appreciate the benefits of concepts like type
> safety.  Strong typing is incorrectly viewed as "academic" and counter
> to progress.

Ada was designed to induce a change in mentalities. A change in 
mentality is much harder to introduce than a change of programming language.

Moreover, training is felt by management as a waste of time and money. 
Why should we pay to get our engineers not working for a week or two?
This newly hired guy does not know Ada? Just give him some code to read 
(Ada is so readable after all); he's a talented guy, he will learn 
quickly. In only rare cases, the guy is given Barnes' book (not to be 
read during work hours).

Currently, we see many projects in Ada, and at the same time the 
attendance to my training sessions has never been so low. I'm worried, 
not for my business (the said projects provide me with enough 
occupation), but for this growing idea that proper training is not 
necessary.

I just added a new rule to AdaControl (available in the next release) to 
check "while true loop .. end loop;". I did so because I found it in 
actual programs. It is a great indicator of modules written by people 
without any Ada education, and which certainly deserve peer review!
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Working with incompetent adaists / unsafe typing war story

[stephe_on_the_web]

Anonymous Coward <anonymous@coward.org> writes:

>   The understanding that most s/w developers seem to have is that they
>   design their own interfaces for packages they create, and users of
>   that ada spec only have a say in whether it meets standards and
>   requirements.  

That seems odd. My view is that interfaces are always negotiated
between the implementers and the users, prefereably with input from
the system architect; they both need the interface, but have different
needs from it. The interface represents the best compromise they can
achieve.

>   I always bend to accommodate types that other developers require
>   in their spec, because it's theirs. Maybe I'm wrong about what I
>   think is typical. It was explained to me that interfaces are
>   "shared" and are no more controlled by the author than the users
>   of it.

They do have to be controlled; you can't let just anybody force a
change to an interface.

> That story is just a sample of what I encounter too frequently in the
> Ada workforce.  It seems a /majority/ of ada developers have no formal
> Ada training, and are primarily C developers who picked up the Ada
> syntax on the job.  Consequently, ada principles are lost, and much of
> the ada code out there is only slightly safer than C code (but still
> safer primarily because even a poor Ada developer cannot write
> ambiguous code like they can in C).

In my experience, most programmers have inadequate training. Most of
my current job is teaching people how to write good code. I find it
helps that I'm also teaching them Ada; it helps them to abandon their
preconceptions. It does give Ada a rep of being "hard to learn", but I
can live with that.

> I've only worked on four or so workplace ada projects.  The projects
> with elaborate coding standards produced substantially better code,
> but I think it was just chance that those projects also had Ada
> enthusiasts who used private types, as the coding standard did nothing
> to promote private typing.

I suspect that's a mindset issue; if you like elaborate coding
standards, you are likely to also like private types and strong
typing.

> Do you folks encounter this frequently?  

Yes.

> And what's the solution? 

Programmer education and strong project management.

> Management can never appreciate the benefits of concepts like type
> safety. 

That's not true. Managers need to be educated along with the
programmers.

The best way to educate managers is by demonstrating an impact on the
bottom line. If you can show that good programming actually saves time
and therefore money, they will listen. 

But you need support in getting that process started. That's when you
need stories from others that have used good programming and saved
money; check http://www.adaic.com for good stories.

On the other hand, some programmers will never be "good", and you need
to get them off your project.

> Strong typing is incorrectly viewed as "academic" and counter to
> progress.

Unfortunately, we don't have a good database of examples to show this
is wrong. In my job, I have sufficient clout that I can say "on my
projects we use Ada, because it is the best language". However, other
project managers don't want to be bothered with learning new tools, or
training their staff; they are unconcerned about productivity.

Since I work for the government, it's hard to use the profit motive.
Instead, it helps to remember that our real purpose is to spend the
taxpayer's money in the congress-critter's district. That explains why
we often do things in the most inefficient way :).

-- 
-- Stephe

Re: Working with incompetent adaists / unsafe typing war story

[Peter C. Chapin]

Jean-Pierre Rosen <rosen@adalog.fr> wrote in
news:bbd1td.6ck.ln@hunter.axlog.fr: 

> Ada was designed to induce a change in mentalities. A change in 
> mentality is much harder to introduce than a change of programming
> language. 

I agree with this. It also works in another direction... I believe I became 
a significantly better C programmer after studying Ada. Like all good 
programming techniques, the concepts end up being language independent.

Peter

Re: Working with incompetent adaists / unsafe typing war story

[Ludovic Brenta]

Anonymous Coward <anonymous@coward.org> writes:
> I'd like to start with a war story:

[...]

> That story is just a sample of what I encounter too frequently in
> the Ada workforce.  It seems a /majority/ of ada developers have no
> formal Ada training, and are primarily C developers who picked up
> the Ada syntax on the job.  Consequently, ada principles are lost,
> and much of the ada code out there is only slightly safer than C
> code (but still safer primarily because even a poor Ada developer
> cannot write ambiguous code like they can in C).
>
> I've only worked on four or so workplace ada projects.  The projects
> with elaborate coding standards produced substantially better code,
> but I think it was just chance that those projects also had Ada
> enthusiasts who used private types, as the coding standard did
> nothing to promote private typing.
>
> Do you folks encounter this frequently?  And what's the solution?
> Management can never appreciate the benefits of concepts like type
> safety.  Strong typing is incorrectly viewed as "academic" and
> counter to progress.

At Barco, I am part of a small team that has been using Ada for the
past 8 years or so.  I've been there for only two years myself.  My
colleagues are software engineers, not just coders.  They all
understand the power of type safety, and their desks have badges with
the Countess' effigy and the motto: "In strong typing we trust - Ada -
1983 - 1995 - 2005".  Last year, I wrote the new version of the coding
standard, and everyone on the team has a culture of following it.  So,
my experience is quite exactly the opposite of yours, and as a
consequence I'm a happy software engineer :)

-- 
Ludovic Brenta.

Re: Working with incompetent adaists / unsafe typing war story

[adaworks]

"Anonymous Coward" <anonymous@coward.org> wrote in message
news:VeRIf.30362$3V4.15715@trnddc06...
>
> Do you folks encounter this frequently?  And what's the solution?
> Management can never appreciate the benefits of concepts like type
> safety.  Strong typing is incorrectly viewed as "academic" and counter
> to progress.
>
I was at an Ada conference many years ago, before the end of the
mandate, and visiting the booth of a well-known CASE tool
publisher.   They began to demonstrate the tool for me.

At one point the person doing the demonstration said something
such as, "Well let's get rid of these limited private types since they
cannot be used for anything useful."   He then continued with his
demonstration of the tool.

I was horrified, but decided to remain polite.   It would have been
no good to try to educate him to the contrary.

From an engineering perspective (although not from a programmer's
point-of-view) it is quite valuable that we cannot overload the
assignment operation and do other little things that are easy in
languages without the equivalent of limited private.   Yes, to do
assignment on a limited type we must create a procedure, but that
is not a bad thing -- it is a good thing.

One of my early mentors in Ada, Doug Bryan, once said, "Until
you understand 'limited' you don't understand Ada."   I eventually
learned just how right he was.

With Ada, we are not trying to appeal to the programmer.  Rather,
we are concerned with good engineering practice.   Ada continues
to be the best language available when one is focused on engineering
rather than programming.

Richard Riehle

Re: Working with incompetent adaists / unsafe typing war story

[Brian May]

>>>>> "Anonymous" == Anonymous Coward <anonymous@coward.org> writes:

    Anonymous> I'd like to start with a war story: <war story>

A big hurdle I find (not just in Ada software) is that the API Mr
Safety carefully designed and implemented is insufficient for the
requirements of the project. As a result, and due to demands from
management to get the project finished Yesterday, Mr Safety is forced
to expose a lot of the inner workings which he never intended.

The reason why the API was insufficient? Because Mr. Safety didn't
understand all of the requirements. The reason? Because management
considers the design phases of the very complicated software a
complete waste of time and money. Bugs will occur anyway. What is the
point? However, Mr. Safety wanted to try to do the right thing. So he
tried to do the design. Unfortunately he couldn't see into the future
for what would be required, as Management considers each modification
as a totally isolated project.

Not only that, but Mr. Safety wasn't given time to document the
API. As such other programmers tied themselves up in knots, either by
continuing to do things in obsolete ways, or by making changes to the
API that aren't required and break other things in horrible ways. This
can lead to conflicts between Mr. Safety and the other programmers in
doing things the "correct way" vs the "quickest way" with management
supporting the later. Not only that, but even Mr. Safety wasn't sure
how the API was meant to work, as he wrote it years ago and hasn't had
an opportunity to look at it since. During this time other developers
have gradually been changing it in ways which look totally
inappropriate and Mr. Safety doesn't understand.

At the end of the day, management gets code that appears to work, and
they are happy. Other code might be completely broken and need fixing,
but that is rule rather then the exception in such projects.

These issues occur regardless of language - admittedly this isn't Ada,
and isn't even I strongly typed language, but I think Ada wouldn't
help without significant culture change.


If on the other hand you built a house and then tried to design it in
a similar manner, I could imagine:

Customer: "Build me a house, and put it right there please."

Builder: "What are the requirements of this house? Is this your
property? How many bedrooms? How many bathrooms?"

Customer: "What is this? Don't waste time.  I want big rooms. Just
build me a house, and quickly too, so I don't have to pay you too
much."

[...]

Builder: "Your house is finished. If there are any problems, please
let me know".

Customer: "I like the very large lounge room with the big windows. How
do I get inside?"

Builder: "Just smash a hole in the Window like this, until you can fit
inside. Try not to cut yourself."

Customer: "Is this secure?"

Builder: "Off course it is. No intruder would dare try to enter at the front."

builder to himself: "...as long as the back door, with all the signs
'Emergency entrance here! No key required!', remain a secret."

[...]

Customer: "I need the toilet. Can you please show me the way?"

Builder: "Whoa! You didn't say you wanted a toilet! I only built a
lounge room. The toilet would require water connections, sewage
connections, another floor, council approvals, and will cost you
extra."

Customer: "I thought a toilet was standard. I also want a bathroom
too. A stranger I met on the street said a bathroom is always a good
idea. This is unacceptable. Don't waste time with the council
approvals, just finish my house!"

[...]

Builder: "Here is the extra story attached to the roof of your house
containing a bathroom and toilet. As an extra bonus I have also given
you a shower and a big Spa bath. You can get to it by climbing out the
main Window. The addition should be secure, I used plenty of duct
tape."

Customer: "Spare me the technical details. Is it finished or not?"

Builder: "It is finished."

Customer: "Can you make my new oven work when it gets delivered?"

Builder: "umph. There isn't a Kitchen."

Customer: "What is the kitchen anyway? I don't know what it means. I
purchased an oven, it a good one, because it was expensive, and the
Microsoft representative told me to get this one. Just get it
working. He said it would produce anything from roast meals to cakes
and biscuits with minimal effort."

Builder: "I think you want a Kitchen. Let me see... That would require
an additional story, additional plumbing, ..."

Customer: "Whatever, just do it."

[...]

Customer: "The oven doesn't work! The Microsoft person told me it was
your fault."

Builder: "You didn't tell me to connect it! Is it Electric or Gas?"

Customer: "I don't know the process. I just wanted you to make it work
when it gets delivered."

Builder: "It is not even delivered yet? No wonder it isn't working. Is
it Microwave, Electric or Gas?"

Customer: "How am I suppose to know? You tell me!"

Builder: "I could do this job faster if you told me. Besides,
connecting ovens really isn't in my job description..."

Customer: "This is beyond a joke. Who knows what on earth you are
talking about anyway."

[...]

Customer: "It is getting dark. How do I make it light?"

Builder: "What? You want lights? Do you want an electrician?"

Customer: "No! I don't even understand anything you just said. Just
make it light!"

[...]

Customer: "Where do I put my bed?"

Builder: "In the lounge room. In front of the big window that looks
out towards the big shopping centre. I surely hope you don't need
privacy?"

Customer: "No! Whats that?"

[...]

Customer: "Your house you built me was faulty. It was buggy and
crashed into the old house underneath. All I did was remove the duct
tape so I could re-program the bugs. It didn't meet any of my
requirements either. My oven doesn't work either - it just gets very
hot. I will send you a draft copy of my requirements later. I want a
full refund, and I want you to fix up the damage to the old house."

Builder (horrified): "You did what with the duct tape??? [...] What
old house underneath??? [...] There were no bugs when I left
it. Besides how do you re-program a bug??? Do you even know what you
are talking about?"

    Anonymous> Do you folks encounter this frequently?  And what's the
    Anonymous> solution?  Management can never appreciate the benefits
    Anonymous> of concepts like type safety.  Strong typing is
    Anonymous> incorrectly viewed as "academic" and counter to
    Anonymous> progress.

I have seen web pages dedicated to discussing why strong typing
systems are bad and slow implementation, and the world would be a much
better place if everyone used typeless scripting languages instead.

Then people ask how come so many web pages have obvious and known
security holes. There was a talk at the Linux conference (LCA2006),
New Zealand, in fact. The speaker wrote a program designed to check
websites against obvious attacks, such as not quoting user input
before displaying it back as HTML to the user, or displaying unquoted
user input (meaning HTTP post variables) in SQL error messages. He
found so many security problems in common websites around the Internet
he refuses to distribute the code for fear that attackers might use
it.

These things shouldn't happen!

Oh well, such is life...

I only hope that software written for mission critical applications is
better...
-- 
Brian May <bam@snoopy.apana.org.au>

Re: Working with incompetent adaists / unsafe typing war story

[Anonymous Coward]

In article <uwtfvwqod.fsf@acm.org>, 
stephe_on_the_web@toadmail.com wrote:
> 
>> And what's the solution? 
> 
> Programmer education and strong project management.

That's how a company would handle the problem, but what about the peon
who's forced to work in a sloppy environment?  I guess I need to know
how to select a project.  It seems I will need to question an ada
developer in my future job interviews to determine whether I'm dealing
with a competent program.  If private types are not at least
encouraged, I'll turn the job down.

>> Management can never appreciate the benefits of concepts like type
>> safety.
> 
> That's not true. Managers need to be educated along with the
> programmers.
> 
> The best way to educate managers is by demonstrating an impact on
> the bottom line. If you can show that good programming actually
> saves time and therefore money, they will listen.

Maybe I'm just dealing with a tough crowd.  A systems fella ordered a
change on one of my private types, forcing me to represent the same
type with a different set of numbers (a change in coordinate systems
to be exact).  Because it was a private type, I only needed to make
that change in ONE package; which took me about 15-20 minutes (the
same change would have taken most of the day if the type were public).
When I explained to him how trivial the change was, and what the
impact would be if the type had been public, it should have served as
an excellent demonstration of strong typing on the bottom line.  Yet
he shrugged it off, seemingly unconvinced.  I imagine he was thinking
that the savings from that requirements change is outweighed by the
cost of all the "extra effort" that pro-weak typing developers claim
they would endure.

What's interesting is this project is well over budget, and management
is begging for ideas to save money.  This is the same project that is
allowing the unskilled developers to create weak-typed versions of
pre-existing polished private types.  And of course rather than
converting the public types to their private versions to use the
library that exists, they are also duplicating the math within each of
their packages.  It's not my money that being pissed away, but I still
hate to be around it.

Re: Working with incompetent adaists / unsafe typing war story

[Anonymous Coward]

In article <87zmkrqcs5.fsf@ludovic-brenta.org>, 
Ludovic Brenta wrote:
> 
> They all understand the power of type safety, and their desks have
> badges with the Countess' effigy and the motto: "In strong typing we
> trust - Ada - 1983 - 1995 - 2005".  Last year, I wrote the new
> version of the coding standard, and everyone on the team has a
> culture of following it.  So, my experience is quite exactly the
> opposite of yours, and as a consequence I'm a happy software
> engineer :)

What would one put on their resume to selectively stand out to these
companies, and simultaneously deter the sloppy projects from offering
an interview?

Re: Working with incompetent adaists / unsafe typing war story

[Jeffrey R. Carter]

Anonymous Coward wrote:

> What's interesting is this project is well over budget, and management
> is begging for ideas to save money.  This is the same project that is
> allowing the unskilled developers to create weak-typed versions of
> pre-existing polished private types.  And of course rather than
> converting the public types to their private versions to use the
> library that exists, they are also duplicating the math within each of
> their packages.  It's not my money that being pissed away, but I still
> hate to be around it.

You should check out the ACM/IEEE-CS SW engineering code of ethics. Reducing the 
quality of your SW is a violation of principle 3: "Software engineers shall 
ensure that their products and related modifications meet the highest 
professional standards possible." So, if you want to be an ethical SW engineer, 
you should refuse to cooperate with such requests.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: Working with incompetent adaists / unsafe typing war story

[Jeffrey R. Carter]

Brian May wrote:

> I only hope that software written for mission critical applications is
> better...

One would, but it often isn't. I've seen Do178B Level A SW where the principal 
design rule is to create a global variable. These systems have 100s of packages 
and 1000s of global variables, none of them documented. You're expected to read, 
understand, and retain the bodies of every package in order to deal with any 
part of the system.

-- 
Jeff Carter
"Sheriff murdered, crops burned, stores looted,
people stampeded, and cattle raped."
Blazing Saddles
35

Re: Working with incompetent adaists / unsafe typing war story

[Jerome Hugues]

In article <bbd1td.6ck.ln@hunter.axlog.fr>, Jean-Pierre Rosen wrote:
> Anonymous Coward a �crit :
>> [War story snipped]
>> Do you folks encounter this frequently?  And what's the solution?
>> Management can never appreciate the benefits of concepts like type
>> safety.  Strong typing is incorrectly viewed as "academic" and counter
>> to progress.
> 
> Ada was designed to induce a change in mentalities. A change in 
> mentality is much harder to introduce than a change of programming language.

<fun>
You can always cheat a little bit ;)

http://thedailywtf.com/forums/60255/ShowPost.aspx
"The Secret to Better C" 
</fun>

-- 
Jerome

Re: Working with incompetent adaists / unsafe typing war story

[Stephen Leake]

Jerome Hugues <hugues@vautrin.enst.fr> writes:

> <fun>
> You can always cheat a little bit ;)
>
> http://thedailywtf.com/forums/60255/ShowPost.aspx
> "The Secret to Better C" 

Some people clearly have way too much time on their hands!
> </fun>

-- 
-- Stephe

Re: Working with incompetent adaists / unsafe typing war story

[Simon Clubley]

In article <bbdJf.1138$VI6.786@newsread1.news.pas.earthlink.net>, "Jeffrey R. Carter" <spam@spam.com> writes:
> 
> One would, but it often isn't. I've seen Do178B Level A SW where the principal 
> design rule is to create a global variable. These systems have 100s of packages 
> and 1000s of global variables, none of them documented. You're expected to read, 
> understand, and retain the bodies of every package in order to deal with any 
> part of the system.
> 

Given the level of documentation these certification efforts are reported to
require, how does something like that actually get certified for production
use ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
If Google's motto is "do no wrong", then how did we get Google Groups 2 ?

Re: Working with incompetent adaists / unsafe typing war story

[Marc A. Criley]

Dennis Lee Bieber wrote:
> On Thu, 16 Feb 2006 23:57:01 GMT, <adaworks@sbcglobal.net> declaimed the
> following in comp.lang.ada:
> 
>>One of my early mentors in Ada, Doug Bryan, once said, "Until
> 
> 	Now there is a name I haven't heard in 17 years... If it's the same
> Doug Bryan, he was a member of a gaming group I was in...

An Ada seminar run by Doug that I attended quite some time ago continues 
to exert a profound influence on my Ada programming practice and 
undestanding.  In that seminar he focused on Ada's "type model" and how 
that was the foundation of the language's definition.  The proper 
definition of types embeds mountains of useful information about your 
program that can be programmatically extracted by querying the type 
model for that information, which is mostly done via attributes.

That's why I occasionally get on the soapbox that while "strong typing" 
is a strength of Ada, it's only _part_ of the story, the rest is having 
access to information about types and their instances that is being 
implicitly encoded into the software due to Ada's type model based 
definition.

With the fallacious dismissal of strong typing, not only the defensive 
aspects of Ada are being thrown out, but the revelatory ones as well.

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Working with incompetent adaists / unsafe typing war story

[Simon Wright]

<adaworks@sbcglobal.net> writes:

> At one point the person doing the demonstration said something such
> as, "Well let's get rid of these limited private types since they
> cannot be used for anything useful."  He then continued with his
> demonstration of the tool.

On my project, we have been using a code generator whose runtime makes
use of limited private abstract tagged types[1] where appropriate, and
doing unit tests with AUnit. AUnit ends up with a lot of unit test
code (seems to be about three times the operational code), so there's
an interest in finding a more cost-effective tool (I rather think that
what we want is a more cost-effective way of testing the code, which
is not quite the same thing, but that's another story).

At least one of the tools we looked at seemed to be incapable of
dealing with limited and/or indefinite types. I only got called in as
the eval was winding down, so I don't know the full story, but at
least one possibility is that the market for fancy test support
environments is one where limited and/or indefinite types are banned
anyway, for safety-related reasons perhaps, so it's not a problem. But
_I_ have a problem with an Ada test tool that can only handle a subset
of Ada, and I'm reluctant to modify the code generator to produce Ada
I'd be ashamed to write myself.

I _have_ been modifying the code generator to provide better support
for (AUnit-style) testing; for example, it can generate stub versions
of packages where you can store the values of in parameters, specify
the values returned via out parameters/function returns, and cause
exceptions to happen, all with indefinite values (but not limited);
implemented using streams. All easy enough if you're generating the
code in the first place, probably more work with ASIS.

[1] I think I got the order wrong there!

Re: Working with incompetent adaists / unsafe typing war story

[Jeffrey R. Carter]

Simon Clubley wrote:

> Given the level of documentation these certification efforts are reported to
> require, how does something like that actually get certified for production
> use ?

There are a number of things that are done for certification. For DO-178B code, 
they manually examine the generated object code to make sure that it looks as 
expected, for example.

Then, of course, they do lots of testing. When their tests no longer show the 
presence of errors, they assume that means the absence of errors. If it turns 
out the assumption was wrong, that means they need more tests.

You have to remember that such certification can and is granted to SW in 
assembler. Ada with thousands of global variables is probably no worse than that.

-- 
Jeff Carter
"I spun around, and there I was, face to face with a
six-year-old kid. Well, I just threw my guns down and
walked away. Little bastard shot me in the ass."
Blazing Saddles
40

Re: Working with incompetent adaists / unsafe typing war story

[Pascal Obry]

Simon Wright a �crit :

> [1] I think I got the order wrong there!

Yep: it's abstract tagged limited private.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Working with incompetent adaists / unsafe typing war story

[Stefan Lucks]

> AUnit ends up with a lot of unit test code (seems to be about three
> times the operational code), so there's an interest in finding a more
> cost-effective tool (I rather think that what we want is a more
> cost-effective way of testing the code, which is not quite the same
> thing, but that's another story).

A lightweight alternative to AUnit may be tg, see
    http://www.free-software-consulting.com/projects/tg/index.html

While tg follows a very simple straightforward approach to generating
test code, I found it very nice for teaching purposes.


-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------

Re: Working with incompetent adaists / unsafe typing war story

[Pascal Obry]

Stefan Lucks a �crit :
> A lightweight alternative to AUnit may be tg, see
>     http://www.free-software-consulting.com/projects/tg/index.html
> 
> While tg follows a very simple straightforward approach to generating
> test code, I found it very nice for teaching purposes.

I've been using it also and found it quite nice.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Working with incompetent adaists / unsafe typing war story

[Ludovic Brenta]

Anonymous Coward <anonymous@coward.org> writes:

> In article <87zmkrqcs5.fsf@ludovic-brenta.org>, 
> Ludovic Brenta wrote:
>> 
>> They all understand the power of type safety, and their desks have
>> badges with the Countess' effigy and the motto: "In strong typing we
>> trust - Ada - 1983 - 1995 - 2005".  Last year, I wrote the new
>> version of the coding standard, and everyone on the team has a
>> culture of following it.  So, my experience is quite exactly the
>> opposite of yours, and as a consequence I'm a happy software
>> engineer :)
>
> What would one put on their resume to selectively stand out to these
> companies, and simultaneously deter the sloppy projects from offering
> an interview?

I think you can just explain what you're looking for in your CV.  Then
add a couple of keywords such as "quality", "coding standards" and
"software engineering".

If you evolve to that point (I haven't yet but am planning to), you
can replace these keywords with "formal methods", "proof of
correctness", "SPARK".

It has worked for me at least.

-- 
Ludovic Brenta.

Re: Working with incompetent adaists / unsafe typing war story

[Simon Wright]

Stefan Lucks <lucks@th.informatik.uni-mannheim.de> writes:

> A lightweight alternative to AUnit may be tg, see
>     http://www.free-software-consulting.com/projects/tg/index.html

Yes, I'd forgotten about that.

I can't remember quite why we decided to go with AUnit rather than tg
-- I know we did a comparison, and I think they were quite close --
but it was roughly:

* AUnit is supported by AdaCore as part of GNATpro.

* tg didn't handle some structural features we needed (it may have
  been where the test driver needed to be a child unit) without
  patching.

Also, I'm not sure that it would make that much difference. A lot of
the test code is setting up the exact niggly details, which is much
the same in tg and AUnit.

Re: Working with incompetent adaists / unsafe typing war story

[adaworks]

"Anonymous Coward" <anonymous@coward.org> wrote in message
news:p9cJf.34455$lo3.34072@trnddc07...
>
> Maybe I'm just dealing with a tough crowd.  A systems fella ordered a
> change on one of my private types, forcing me to represent the same
> type with a different set of numbers (a change in coordinate systems
> to be exact).  Because it was a private type, I only needed to make
> that change in ONE package; which took me about 15-20 minutes (the
> same change would have taken most of the day if the type were public).

Someone recently encountered a problem with a package I wrote years
ago that had a limited private type.  It seems I had overlooked one possible
requirement (method)  for that type. The need for the method is rare but I
should
have anticipated it.   No one ever encountered the problem before, as far as
I know.

It took me five minutes to add a specification for that method and about as
long to write an implementation for it in the package body.  The algorithm
was simple to implement, but did involve an if statement.   Had programmers
been able to write their own code for the functionality of this method, the
probability of some of them getting it wrong was low, but still possible.  In
this
case, the algorithm was testable in one place rather than scattered about.

If I had declared the type as non-limited, or had used a pre-defined type,
the absence of the method would never have manifested itself.   Users would
have simply carried on without thinking about it.  From this example, some
designers might suppose that the type should not have been limited.   My
own view is that we learned something from discovering the need for this
method.   Also, I ended up thinking more deeply about what other methods
might be required in the future.  I did not come up with anything else.

Unfortunately we did have to recompile the package specification, but that did
not seem to present any hardship. More important, the internal strucutre of
instances of the type continue to be unreachable by users of the package.

Richard Riehle

Re: Working with incompetent adaists / unsafe typing war story

[Stephen Leake]

<adaworks@sbcglobal.net> writes:

> Someone recently encountered a problem with a package I wrote years
> ago that had a limited private type. It seems I had overlooked one
> possible requirement (method) for that type. The need for the method
> is rare but I should have anticipated it. No one ever encountered
> the problem before, as far as I know.

No package is ever perfect :).

> It took me five minutes to add a specification for that method and
> about as long to write an implementation for it in the package body.
> The algorithm was simple to implement, but did involve an if
> statement. Had programmers been able to write their own code for the
> functionality of this method, the probability of some of them
> getting it wrong was low, but still possible. In this case, the
> algorithm was testable in one place rather than scattered about.


That is why open source libraries are so valuable; we can fix problems
in the right place, instead of working around them.

-- 
-- Stephe

Re: Working with incompetent adaists / unsafe typing war story

[Anonymous Coward]

In article <sa4y80a7nml.fsf@snoopy.microcomaustralia.com.au>, Brian May wrote:
>>>>>> "Anonymous" == Anonymous Coward <anonymous@coward.org> writes:
> 
>    Anonymous> I'd like to start with a war story: <war story>
> 
> A big hurdle I find (not just in Ada software) is that the API Mr
> Safety carefully designed and implemented is insufficient for the
> requirements of the project. As a result, and due to demands from
> management to get the project finished Yesterday, Mr Safety is forced
> to expose a lot of the inner workings which he never intended.

That sounds backwards to me.  It is public (exposed) types that are
fragile to change, not private types.  Perpetually changing
requirements have minimal adverse impact when private types are used.

> The reason why the API was insufficient? Because Mr. Safety didn't
> understand all of the requirements. The reason? Because management
> considers the design phases of the very complicated software a
> complete waste of time and money. Bugs will occur anyway. What is
> the point? However, Mr. Safety wanted to try to do the right
> thing. So he tried to do the design. Unfortunately he couldn't see
> into the future for what would be required, as Management considers
> each modification as a totally isolated project.

Seeing into the future is not required with private types.
Furthermore, the mandate to use public types was not motivated by a
requirements change.  The package meets the requirements.  A developer
(Mr. Sloppy) who has principaled objections to strong types motivated
the change so he would not have to use the import routines that were
already available to him.  He simply did not want to instantiate the
object that was needed to use the API, so he drove management to force
direct support for a public version of the same type.

I should mention the pathetic /official/ reason for Mr. Sloppy's
actions.  To leverage the mandate, he only needed to convince a
systems lead.  So the reasoning he used was that he did not want to
'with' in another package (the package containing the type declaration
that the API referenced).  He was already with'ing a types package
(that is, a package containing a large messy collection of
unassociated public types), and he felt that he should only have to
'with' these types packages in order to use an API.

> Not only that, but Mr. Safety wasn't given time to document the
> API. As such other programmers tied themselves up in knots, either by
> continuing to do things in obsolete ways, or by making changes to the
> API that aren't required and break other things in horrible ways. This
> can lead to conflicts between Mr. Safety and the other programmers in
> doing things the "correct way" vs the "quickest way" with management
> supporting the later.

Sometimes the "correct" way IS the "quickest" way.  Looking at the
business case, it would have been much quicker for the API user to
make a single function call to convert his object to the protected
object, compared to what it would take to change the interface, thus
the architecture, and impact the API along with every user package
that was already using the private type.  The effort saved Mr. Sloppy
(who works direct) 15-20 minutes, at the cost of paying a contractor
copious hours to downgrade code that was already correct (and tested
as such).  After a substantial fight (which I almost didn't attempt),
I was able to introduce public versions without tossing out the
private typed interfaces, so only the API package was adversely
affected.

I said earlier that it's not my money that was pissed away - but it
just occurred to me - I'm a taxpayer :(

Re: Working with incompetent adaists / unsafe typing war story

[Brian May]

>>>>> "Anonymous" == Anonymous Coward <anonymous@coward.org> writes:

    Anonymous> That sounds backwards to me.  It is public (exposed)
    Anonymous> types that are fragile to change, not private types.
    Anonymous> Perpetually changing requirements have minimal adverse
    Anonymous> impact when private types are used.

It is backwards. Unfortunately, when code is poorly documented, other
programmers have a habit of "fixing" problems by changing the API,
when in actual fact the API was never broken. In many cases, the API
was working exactly as initially designed.

    Anonymous> Seeing into the future is not required with private

True. But designing the public API correctly requires some ability to
make it flexible enough to ensure compatibility with future
requirements.

Also I have seen code that calculates/retrieves a number of values and
calls another module via public API function. This function in turn
calculates/retrieves the exact same set of values (as passing them
isn't part of the public API as it was originally written) and calls
another function. Repeat.  This is in code that needs to execute fast,
but ends up being very inefficient. The Management solution? Get a
faster computer.

The other side of the coin though is people who over-design.  Also
there are the people who use standards, because they are "cool",
instead of "appropriate solution". For example, ever considered
storing configuration settings and (large amounts of) low level data
in XML in a SQL database text field? This is in web based application
where speed is desirable. I got this code after the previous staff
member responsible left - I decided that fixing the code meant
understanding it first, and it would be much quicker and simpler to
rewrite from scratch. True, my code isn't anywhere near as flexible as
before, but most of that extra flexibility isn't required and may
never be required (despite client initially saying otherwise). My code
is easier to easier to understand as it doesn't have numerous layers
of undocumented APIs to try to shuffle through. It also stores the low
level data straight into the SQL database without converting to XML
first.

    Anonymous> types.  Furthermore, the mandate to use public types
    Anonymous> was not motivated by a requirements change.  The
    Anonymous> package meets the requirements.  A developer
    Anonymous> (Mr. Sloppy) who has principaled objections to strong
    Anonymous> types motivated the change so he would not have to use
    Anonymous> the import routines that were already available to him.
    Anonymous> He simply did not want to instantiate the object that
    Anonymous> was needed to use the API, so he drove management to
    Anonymous> force direct support for a public version of the same
    Anonymous> type.

Yuck.

    Anonymous> I should mention the pathetic /official/ reason for
    Anonymous> Mr. Sloppy's actions.  To leverage the mandate, he only
    Anonymous> needed to convince a systems lead.  So the reasoning he
    Anonymous> used was that he did not want to 'with' in another
    Anonymous> package (the package containing the type declaration
    Anonymous> that the API referenced).  He was already with'ing a
    Anonymous> types package (that is, a package containing a large
    Anonymous> messy collection of unassociated public types), and he
    Anonymous> felt that he should only have to 'with' these types
    Anonymous> packages in order to use an API.

With compiled code, at least you don't have a run-time performance
impact for importing other packages (unlike ... lets say a PHP
program, with lets say a hundred or more packages that need to be
loaded for every web request).

    Anonymous> Sometimes the "correct" way IS the "quickest" way.

I agree. Unfortunately, people these days are out for "short-term
gain" and rarely realize that this leads to "long-term problems".

    Anonymous> Looking at the business case, it would have been much
    Anonymous> quicker for the API user to make a single function call
    Anonymous> to convert his object to the protected object, compared
    Anonymous> to what it would take to change the interface, thus the
    Anonymous> architecture, and impact the API along with every user
    Anonymous> package that was already using the private type.  The
    Anonymous> effort saved Mr. Sloppy (who works direct) 15-20
    Anonymous> minutes, at the cost of paying a contractor copious
    Anonymous> hours to downgrade code that was already correct (and
    Anonymous> tested as such).  After a substantial fight (which I
    Anonymous> almost didn't attempt), I was able to introduce public
    Anonymous> versions without tossing out the private typed
    Anonymous> interfaces, so only the API package was adversely
    Anonymous> affected.

My concern is that the software design and development industry gets a
bad reputation of being "late", "buggy", "over-budget". I think many
of these problems are caused by shortcuts taken through the process.

...and lets face it, the vendor who quotes the lowest price on
software to be written is most likely to get the contract. This in
turn is likely to be the vendor that is willing to make the most
shortcuts in order to get the price down. Not just in software
engineering. I have heard this in other engineering projects, from
people involved.
-- 
Brian May <bam@snoopy.apana.org.au>