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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dc89792b5613be6a X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Converting Ada Tasks To VxWorks Tasks? Date: 2000/04/16 Message-ID: <8dc9t9$lij$1@nnrp1.deja.com>#1/1 X-Deja-AN: 611809686 References: <1crJ4.142$d21.18564@elnws01> <38F6623B.C365A224@acm.org> <38F79EA3.84D28C46@raytheon.com> X-Http-Proxy: 1.0 x30.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sun Apr 16 11:58:37 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-04-16T00:00:00+00:00 List-Id: In article , "Michael Hartsough" wrote: h > Won't work. Official policy is that nobody's indispensible. > especially an Ada & Multitasking Advocate. ;^) A bit off topic, but I really feel like making a comment on this point. I agree that any company should have an official policy that no one is indispensable, and should orient the structure of development according to this point. After all if an indispensable person is in a fatal accident, the company can be very seriously impacted. This is one of the reasons at Ada Core Technologies that I have very strongly insisted on avoiding a situation where only one person knows some code, and no one else can touch it. There are two approaches that help: 1. Avoid the use of author's names on units, or anything else that encourages the notion of ownership. Some formal configuration management procedures actually encourage or even insist on the idea that only one person can control changes to a unit, but I think that's a very bad idea. 2. Insist on a highly uniform coding style, so that anyone feels comfortable with anyone else's code. You know you are beginning to succeed here when A writes some chunk of code, or perhaps a whole unit, and B fixes a bug in it, and A's reaction is "great, that's one bug I don't have to fix", instead of "Hey! What's B doing mucking in *my* code?" I have been in far too many situations at other companies where the second reaction is typical, and where individuals have idiosyncratic coding styles that tend to discourage the situation in the first place. That being said, I find it extraordinary, and extremely misguided that for many large companies, the policy of avoiding indispensibility gets transmogrified to a viewpoint that everyone is interchangable, and that, for example, if you want to cut your work force, it doesn't matter who goes. The fact remains that productivities vary hugely in our field, and management failing to note this fact when they decide who to retain is a very serious problem in companies that make this fundamental mistake. Robert Dewar Ada Core Technologies Sent via Deja.com http://www.deja.com/ Before you buy.