Re: What is wrong with Ada?

[<adaworks@sbcglobal.net>]

"Simon Wright" <simon.j.wright@mac.com> wrote in message 
news:m2hcradpkt.fsf@mac.com...
> <adaworks@sbcglobal.net> writes:
>
>> For example, if we know that a certain programmer always makes
>> mistakes of a certain kind, we can focus more testing on his
>> programs.
>
> Better perhaps to focus more review on the programs and more training
> on the programmer!
>
Programmers are still people.   And people are not interchangeable
parts.  They come to us with a variety of skills, aptitudes, and
biases.   While training is an important part of any organization's
activities, we still have some people who are better at one kind of
thing than at another.

For example, we sometimes have programs that require a fair amount
of mathematics.  In an organization, we might have an excellent programming
technician, one who knows the ins and outs of a given language, operating
system, and all the tools.   That same person may not be quite as good in
mathematics as some of our less skilled programmers.

Is it easier to teach good programming to mathematicians or teach mathematics
to programmers?    No one is an expert in everything, and no one can be.  We,
as project managers need to manage people with insufficient skills in one area
or another.   In fact, one of the challenges of management is always the 
management
of ineffective people -- those who might be superior in one area, but not 
another.

With knowledge of the strengths and weaknesses of our team members, we can
make a pretty good guess at what kinds of mistakes might be made.

Sometimes, when a new person comes on the team, we know in advance what the
typical kinds of mistakes are made in our application domain by newcomers.  The
test plan can be focused using that knowledge.

A test plan that anticipates where errors are most likely to occur can go a long 
way
toward improving the testing process, as well as improving the development 
process.
However, for this to work, it is essential that we keep good records -- not just 
for
one project, but for all the projects in our application domain.

A key part of any conventional engineering process is failure prevention.   It 
is not
enough to simply make things (e.g., programs) work.   We must also design to
avoid failure, ensure that failure can be corrected, and to improve on failing 
designs
in future projects.   Failure occurs due to various kinds of stress over 
weakness.
Every design has its stress and its weakness.  Anticipating where there will be 
stress
and corresponding weakness (in people or systems) is one of our principal
responsibilities as engineers.

There are no perfect programmers.  There is no perfect language.  Knowing the
weaknesses helps us prevent stress from turning into failure.

Richard Riehle