lauren@RAND-UNIX.ARPA (10/09/85)
Frankly, I don't think that much of the code quality we see from places
OTHER than AT&T is all that great either. Lots of the non-AT&T programs
I've seen posted are horribly written--not all, but LOTS. But then,
by no means is all AT&T code badly written either. There's good AND
bad code everywhere. There are good AND bad programmers everywhere.
Even code that originally was "good" can be ruined down the line
by "bad" programmers who decide to modify ("improve") it, then do it
badly or just plain wrong, and then distribute the result.
--Lauren--glenn@LL-XN.ARPA (Glenn Adams) (10/09/85)
With all this talk of "good" and "bad" code, I am wondering what value system is being employed in articulating these terms. I would imagine, without digressing into a metasoftware diatribe, that they mean different things to different people. In particular, those who serve to achieve results, i.e., managers who more often than not emphasize short-term goals, probably don't care what the code "looks" like as long as it "works". On the other hand, we programmers who have to "look" at the code, often for long hours seemingly without end, tend to develop a set of values based on our own personal aesthetics. It is on this aesthetic level that code is often judged fish or fowl. But, one may argue that code really doesn't "work" when it "looks" bad. This often comes into play when someone, usually not the original author, must "look" at such code, and "fix" it. Usually, the "fix" involves serious mastication resulting in a different "look" found to be more pleasing to the person performing the "fix". Occasionally, the transformed code which now "looks" good, at least to the most recent author, is made to "work". This usually holds true until the next "fix" must take place, at which time the next author in line displays moral disgust at how that code could "work" and "look" so bad... Glenn Adams
glenn@LL-XN.ARPA (Glenn Adams) (10/10/85)
I agree with you completely. For specific situations such as the one you pointed out, there is obviously little excuse. Especially so since the use of lint would actually have identified most of these problems. What we are really talking about here is the REAL need for Software Quality Control and Assurance. However, without some well defined methodology for attempting quality judgement it is quite difficult to qualify and impossible to quantify by any reasonable metric how a particular piece of code measures up against some ill-articulated standard. An even greater problem is that true quality must begin with a commitment by management to encourage and demand such control. This is where, at least in the past, that I believe has been the greatest weakness. As far as UNIX and C are concerned, I don't think any greater crimes have been committed in this domain of software than any others. It may have been more prudent to invoke lint as an option for 'cc' than make it an independent utility; however, I think it is the integrity of the individual programmer that must prevail. Careful programmers are often condemned by their own management for spending too much time smoothing off the rough edges and running up their software development costs. On the other hand, when careless ones are employed, they may keep the initial development costs low by cutting all corners, but result in extremely high maintenance costs once the system is deployed. I think that this problem is not unique to software but is present in all fields from home-building to the construction of nuclear reactors. This problem is far from being solved and much discussion and thought is still required. What we are talking about here is the real practice, or praxis, of Software Engineering as a professional technique. The Greeks had a word for this which we see quite often these days, he texne, which means the practice of an art in a professional sense: a real skill. Prof. Knuth chose this word as the namesake of TeX, and I think he chose it because it signified that typesetting was an art, yet it required a very professional skill or technique to accomplish a significant work. I would like to see the creation of all software viewed in a similar fashion. Maybe we should continue this discussion in Soft-Eng@MIT-XX.ARPA. Glenn Adams
mjl@ritcv.UUCP (Mike Lutz) (10/12/85)
In article <2012@brl-tgr.ARPA> glenn@LL-XN.ARPA (Glenn Adams) writes: >... It is on this aesthetic level that code is often judged fish >or fowl. But, one may argue that code really doesn't "work" when it "looks" >bad. This often comes into play when someone, usually not the original >author, must "look" at such code, and "fix" it. Usually, the "fix" involves >serious mastication resulting in a different "look" found to be more pleasing >to the person performing the "fix". Of course anyone who doesn't follow *my* style is a troglodyte (and probably a tool of the military-industrial complex to boot) ;-) My rule-of-thumb in fixing others' code is to adopt whatever style they used so that the result is at least consistent. If there is no identifiable style (unfortunately, true of all too many student programs), or the style makes me ill, I rearrange *everything* to follow *my* style. This isn't a perfect solution, especially if I rearrange code that comes from the net, and later see "diff listing" bug fixes. So, I rearrange as infrequently as my highly discriminatory aesthetics permit. The result: tempering of my professional hubris. -- Mike Lutz Rochester Institute of Technology, Rochester NY UUCP: {allegra,seismo}!rochester!ritcv!mjl CSNET: mjl%rit@csnet-relay.ARPA
mikel@codas.UUCP (Mikel Manitius) (10/19/85)
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.
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. However, I would really like to see much tighter
quality control of personel before allowing them to do any work!
I would almost love to name some individuals who caused many problems
in the systems they worked on, perhaps others could avoid them.
Someone somewhere should think of setting up a "credit office" for
programer information, so that "trojan horse" programers would not
last very long.
--
Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikelbaird@bsdpkh.UUCP (Larry Baird) (10/22/85)
> 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. > > -- > Mikel Manitius - ...{ihnp4|akguc|attmail|indra!koura}!codas!mikel FLAME ON!!!!!! If you would like people to consider your ideas, then I would suggest that you enroll in an English grammar class. I would suspect that based upon your above sentence (if we can call it a sentence) that a jr. high school level class would be appropriate. FLAME OFF!!!!! -- It may be that your whole purpose in life is to serve as a warning to others. uucp: ihnp4!bsdpkh!baird Larry A. Baird (lab) uucp: {ihnp4!decvax,peora}!ucf-cs!baird AT&T IS arpa: baird.ucf-cs@csnet-relay Orlando, FL csnet:baird@ucf
alex@rruxc.UUCP (A DeSimone) (10/25/85)
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! **
geoff@desint.UUCP (Geoff Kuenning) (10/27/85)
In article <312@codas.UUCP> mikel@codas.UUCP (Mikel Manitius) writes: >Someone somewhere should think of setting up a "credit office" for >programer information, so that "trojan horse" programers would not >last very long. [to avoid misunderstandings, he's talking about incompetents who can't write C, not people who write "trojan horse" programs] I just ask interviewees to bring along a code sample. If they can't produce one, or I don't like what I see, no job. -- Geoff Kuenning {hplabs,ihnp4}!trwrb!desint!geoff
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/27/85)
> If you would like people to consider your ideas, then I would suggest that > you enroll in an English grammar class. Perhaps the fellow has dyslexia, in which case he didn't do too badly. I agree that good writing is important for effective communication of ideas, but let's judge postings to UNIX-WIZARDS on technical grounds, please, not grammatical.
dave@inset.UUCP (Dave Lukes) (10/30/85)
(Note, I speak here as someone who is a) seldom involved in personnel selection, b) sick and tired of total incompetents being hired simply because they are ``qualified'' to do the job.) In article <132@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >I just ask interviewees to bring along a code sample. If they can't >produce one, or I don't like what I see, no job. That's dangerous (Was the code written by them, or stolen from wherever they last worked?). Ideally, I would like interviewees to be asked to code some small and simple function to a given spec. at the interview. (They would also have to defend their code afterwards against a strong cross examination by the interviewer(s).) This method is also problematic, unfortunately, because many people get frightened by interviews and their ``coding muscles'' would probably freeze up. The main reason I'd like to do this is simply because ``I have 10 years of programming experience'' often really means ``I've managed to avoid actually writing any real code for 10 years by changing jobs whenever my current employer is about to realise how incompetent I am '' (Remember, many projects have long development times, and people are reluctant to sack employees, so it may take a long time ...) Unfortunately, most employers use strange and arcane methods (academic qualifications, references, number of years on the job) when deciding who to employ: none of which actually measures someones ability to DO THE JOB. Yours unqualifiedly, Dave.
henry@utzoo.UUCP (Henry Spencer) (11/03/85)
> Ideally, I would like interviewees to be asked to code some small and simple > function to a given spec. at the interview. Actually, utzoo has occasionally done this, as a follow-on to an interview. (We haven't done it much because we don't do much hiring, and when we do hire, the hiree usually isn't a total stranger.) Our standard test case was a program to turn Unix text (tabs, backspaces, newlines) into fixed- length records with ANSI carriage control. (We used to have a practical application for this, driving a Xerox 9700 laser printer.) It's substantial enough to be a good test of ability, and small enough that you can ask someone to do it without first promising to hire him. It worked well: one applicant who talked well got rejected quickly as hopeless, while Geoff Collyer came up with a neater piece of code than the one we were using in production. (Geoff isn't utzoo!geoff because the spot we had open was for an applications programmer, and somebody else offered him a systems-programming job at about the same time.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry