From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,93a8020cc980d113 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr29.news.prodigy.net.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada References: <1176150704.130880.248080@l77g2000hsb.googlegroups.com> <461B52A6.20102@obry.net> <461BA892.3090002@obry.net> <82dgve.spf.ln@hunter.axlog.fr> <1176226291.589741.257600@q75g2000hsh.googlegroups.com> <4eaive.6p9.ln@hunter.axlog.fr> <1176396382.586729.195490@y5g2000hsa.googlegroups.com> <461E6DD9.6010600@obry.net> <2reWh.1480$H_.1259@newssvr21.news.prodigy.net> Subject: Re: What is wrong with Ada? X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Message-ID: NNTP-Posting-Host: 70.134.100.216 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr29.news.prodigy.net 1177180381 ST000 70.134.100.216 (Sat, 21 Apr 2007 14:33:01 EDT) NNTP-Posting-Date: Sat, 21 Apr 2007 14:33:01 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: Q[R_PJSCTS@QBTLYYZH@^SXBUSXB@DTMNHWB_EYLJZ]BGIELYFWUQBKZQLYJX\_ITFD_KFVLUN[DOM_A_NSYNWPFWNS[XV\I]PZ@BQ[@CDQDPCL^FKCBIPC@KLGEZEFNMDYMKHRL_YYYGDSSODXYN@[\BK[LVTWI@AXGQCOA_SAH@TPD^\AL\RLGRFWEARBM Date: Sat, 21 Apr 2007 18:33:01 GMT Xref: g2news1.google.com comp.lang.ada:15194 Date: 2007-04-21T18:33:01+00:00 List-Id: "Simon Wright" wrote in message news:m2hcradpkt.fsf@mac.com... > 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