Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site rruxc.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!pyuxww!pyuxv!rruxa!rruxo!rruxu!rruxc!alex From: alex@rruxc.UUCP (A DeSimone) Newsgroups: net.unix-wizards Subject: Re: code quality Message-ID: <114@rruxc.UUCP> Date: Fri, 25-Oct-85 11:14:02 EDT Article-I.D.: rruxc.114 Posted: Fri Oct 25 11:14:02 1985 Date-Received: Sat, 26-Oct-85 06:14:14 EDT References: <2012@brl-tgr.ARPA> <8952@ritcv.UUCP>, <312@codas.UUCP> Organization: Bell Communications Research, Piscataway, NJ Lines: 43 Mikel Manitius writes: > I would like to point out one fact about software, companies contract > many consultants, who very often write C software, it has been my > experience in the past, where I have known several consultants > who claimed to be "proficient in C and Unix", who's C code was rediculously > clumsy, and contained indefinite logic problems, I have seen such software > released. I'm a consultant and I don't deny that there ARE consultants (actually contractors is a better term) who don't know what's going on. I've worked with several. I've also encountered many an EMPLOYEE who knew just as little or even less than these "bad" consultants (yes I've worked at AT&T too). Bad consultants usually don't last very long at any one location, at least if they're being properly "supervised". Bad employees sometimes stay on forever, especially in large companies. > Before anyone starts flaming, I am not in any way blaming poor software > on consultants, or blaming consultants for poor software. I was once a > consultant myself. And I'm not blaming poor software on employees either. The blame lies in the areas of personnel screening, project management, and quality control. It seems to me that *all* programmers who join a development effort should be subject to a "trial period" during which their work is closely scrutinized and evaluated. If a consultant is deficient, then fire them. If an employee is deficient, then address the deficiency via training, etc. If that doesn't help, then fire them too. > Someone somewhere should think of setting up a "credit office" for > programer information, so that "trojan horse" programers would not > last very long. I'm not sure that "official" black-lists are legal. I'm sure if anyone published one they'd end up in court. > Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel -- Alex DeSimone, Amala Consultants @ Bell Communications Research ..!{ihnp4,allegra}!rruxc!alex ** Disclaimer? I don't need no stinkin' disclaimer! **