gls@odyssey.ATT.COM (g.l.sicherman) (04/30/89)
> Suppose it is 5 years in the future - 1995 [sic]. You have been > promoted. You are recruiting someone to join your team of "Soft- > ware Engineers." The applicants all have a B.S. in "Software Engi- > neering." --What skills and knowledge do they all have? ... [Long > list of possibilities] Real programmers spend 90% of their time debugging. Computer science curricula ignore debugging, perhaps because it can never be reduced to a theory. But debugging skills are what I would look for *first.* (By the way, I am using "software engineer" as synonymous with "programmer." Separating design from implementation is usually a mistake; ask the DoD.) Other skills I would look for: 2. The ability to "port" software. This is an acid test for distinguishing able programmers from mere C.S. grads. 3. The ability to maintain somebody else's code. Most C.S. students have no experience in this. 4. The ability to work from specifications. This includes getting them changed when they need it, and filling gaps by making inquiries or using your own judgment. 5. The ability to write software with clean, convenient user interfaces. A good programmer can "see" his software from the user's viewpoint and write for the user's benefit. 6. The ability to write adequate user documentation. See 4. 7. Experience with a variety of languages, environments, and methods. Not that this experience will necessarily prove useful, but it shows that the programmer is versatile, and probably understands some of the underlying principles of software environments. By the same token, beware of dogmatism; a programmer with an antipathy to Pascal, COBOL, or VAX/VMS may have a stiff neck. A programmer who stops learning is technologically obsolete. -- Col. G. L. Sicherman gls@odyssey.att.COM
periklis@ecrcvax.UUCP (Periklis Tsahageas) (05/02/89)
Flame on ! In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >> Suppose it is 5 years in the future - 1995 [sic]. You have been >> promoted. You are recruiting someone to join your team of "Soft- >> ware Engineers." The applicants all have a B.S. in "Software Engi- >> neering." --What skills and knowledge do they all have? ... [Long >> list of possibilities] > >Real programmers spend 90% of their time debugging. Computer science Real software engineers spend 100% of their time trying to reduce the time programmers spend on debugging. >curricula ignore debugging, perhaps because it can never be reduced >to a theory. But debugging skills are what I would look for *first.* >(By the way, I am using "software engineer" as synonymous with "programmer." Great mistake, sounds like a voice from the past. >Separating design from implementation is usually a mistake; ask the DoD.) Seperating design from implementation is one of the greatest advances in the field of software engineering (borrowed/stolen from other engineering disciplines). Have you heard of something called data abstraction ? ADT's ? > >Other skills I would look for: > > list of skills deleted > I, absolutely, agree. They are all necessary for a programmer. >Col. G. L. Sicherman >gls@odyssey.att.COM I think software engineering degrees are an attempt by the academia, supported by the software engineering industry, to evolve the craft of current software manufacture into an enginneering discipline. Of course, this is a third year student of Software Engineering (M.Eng.) at Imperial College, London, speaking. -- Periklis Andreas Tsahageas European Computer-Industry Research Centre Arabellastrasse 17, D-8000 Muenchen 81, West Germany +49 (89) 92 69 91 09 USA: periklis%ecrcvax.uucp@pyramid.pyramid.com ...!pyramid!ecrcvax!periklis Europe: periklis@ecrcvax.uucp ...!unido!ecrcvax!periklis
perry@apollo.COM (Jim Perry) (05/02/89)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: > >Real programmers spend 90% of their time debugging. Computer science >curricula ignore debugging, perhaps because it can never be reduced >to a theory. But debugging skills are what I would look for *first.* >(By the way, I am using "software engineer" as synonymous with "programmer." >Separating design from implementation is usually a mistake; ask the DoD.) Unfortunately I believe real debugging skills can only acquired with experience. You can teach techniques for writing relatively bug-free code, the hard part is when you have to debug someone else's code (or spec/interface, whatever). I generally have confidence that my code will do what I intend, but can still have a good time tracking down a subtle bug in the compiler or OS. There's a leap of faith in believing that compilers *have* bugs, the sad realization that most "compiler bugs" aren't, and finally the ability to track down the real ones. >Other skills I would look for: > >2. The ability to "port" software. This is an acid test for distinguishing > able programmers from mere C.S. grads. A lot of this could and should be taught, in the hypothetical S.E. curriculum. >3. The ability to maintain somebody else's code. Most C.S. students have > no experience in this. And the flip side, the ability to write code that can be maintained by somebody else with a minimum of difficulty. There's a trade-off here, in that a programmer in an environment where high standards of maintainability are followed can be at a loss when presented with a more real-world poorly documented program, while a programmer very adept at maintaining bare- bones code may not appreciate the value of the additional work involved in (structuring, documenting, modularizing) code. > >4. The ability to work from specifications. This includes getting them > changed when they need it, and filling gaps by making inquiries or > using your own judgment. > >5. The ability to write software with clean, convenient user interfaces. > A good programmer can "see" his software from the user's viewpoint > and write for the user's benefit. > >6. The ability to write adequate user documentation. See 4. Where "user" under 5 and 6 refers not just to an end user of an application but also clients of libraries, etc. >7. Experience with a variety of languages, environments, and methods. > Not that this experience will necessarily prove useful, but it shows > that the programmer is versatile, and probably understands some of > the underlying principles of software environments. By the same token, > beware of dogmatism; a programmer with an antipathy to Pascal, COBOL, > or VAX/VMS may have a stiff neck. A programmer who stops learning > is technologically obsolete. AMEN. (I have more follow-up material on this but it's getting long so I'll post it separately). -- Jim Perry perry@apollo.com Apollo Computer, Chelmsford MA This particularly rapid unintelligible patter isn't generally heard and if it is it doesn't matter.
render@m.cs.uiuc.edu (05/03/89)
The Colonel gives a good list of skill requirements for software engineers, but I'll be damned if I know how you can judge someone's ability on this kind of stuff unless you've watched them do it. Debugging is something they all should have done on programming assignments, but how do you rate debugging skill? Most undergrads won't have done any porting unless they had some system programming job. Maintenance covers porting and upgrades, but this is also something you don't get anywhere except on a job. Working from specs they should be able to handle; a programming assignment is nothing if not a spec, albeit a poorly worded one. Designing a good user interface is a science in itself, and should be taught as a separate class (or a big part of some other class). Ditto for writing docs. I think that a good CS program will give them some variety of languages and systems (I'd tried 6 or 7 languages by the time I got out of ugrad), and it's easily checked. As I said, a good list, but hard to check. I know the ACM has been working on a core curriculum for undergraduate CS education. Does anyone know how much software engineering is included? Hal Render render@cs.uiuc.edu | uiucdcs!render
gls@odyssey.ATT.COM (g.l.sicherman) (05/03/89)
Dr Hubert Matthews at CERNvax has privately sent me the following note. Since there's nothing here that calls for privacy (is there ever?), I'm restoring the discussion to the public. > From uunet.UU.NET!mcvax!cernvax!hjm Tue May 2 18:43:36 +0200 1989 > > 90%? What sort of programmers do you know? Perhaps the first thing > they should do is learn to write better code in the first place and > reduce that to 50%, or preferably a lot less. Try a course in formal > methods and specifications and see if that doesn't improve things. > Also, try teaching programmers about program testing; if you know the > most common ways that programs fail, then you can avoid those pitfalls > from the start. > > I'm not a CS type. I happen to know about such things as formal > methods, pre- and post-conditions and loop invariants &c., formal > specifications and the like. I also know how to write the most > gawd-awful twisted assembler and get the last drop of performance out > of the machine. I'm an engineer by trade and by training - that's why > I carry the title of Doctor with pride. > > So, get some better programmers, or train your existing ones. Thanks for your note. Indeed, the programmers on my project probably don't spend more than 50% of their time testing and debugging. It depends on where we stand in the development cycle. I do not share your faith in formal methods or methodologies. To me, the work of programming consists of weaving order with chaos. The amount of work to be done is a constant. No amount of external organization or systematic analysis will reduce the need for application and holistic attention, because chaos is unsystematic. The act of programming is a metaphor for the act of living. Still, I wouldn't mind having a better language to code in...! -- Col. G. L. Sicherman gls@odyssey.att.COM
djones@megatest.UUCP (Dave Jones) (05/03/89)
From article <854@odyssey.ATT.COM>, by gls@odyssey.ATT.COM (g.l.sicherman):
> Real programmers spend 90% of their time debugging.
Gack!! The mind boggles.
Who's making all those mistakes? Certainly not a "real programmer".campbell@redsox.bsw.com (Larry Campbell) (05/03/89)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes:
-
-Real programmers spend 90% of their time debugging. Computer science
-curricula ignore debugging, perhaps because it can never be reduced
-to a theory. But debugging skills are what I would look for *first.*
-(By the way, I am using "software engineer" as synonymous with "programmer."
Nonsense. "Software engineer" is not synonymous with "programmer". One of
the differences between a software engineer and a programmer is that, while
a programmer probably does spend 90% of his time debugging, a software
engineer spends, maybe, 25% of his time debugging. Furthermore, a programmer
thinks that spending 90% of his time debugging is perfectly natural, while a
software engineer knows that nearly all bugs are fundamentally preventable,
and that each bug in his code represents a personal failing, to be learned
from and avoided next time around.
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146djones@megatest.UUCP (Dave Jones) (05/04/89)
From article <716@ecrcvax.UUCP>, by periklis@ecrcvax.UUCP (Periklis Tsahageas): > Flame on ! > > In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >>(By the way, I am using "software engineer" as synonymous with >>"programmer." > Great mistake, sounds like a voice from the past. > True. I could not agree more. People who call themselves "software engineers" usually can't program worth squat. Give them five or ten years. They usually start calling themselves programmers about the time they start to catch on. I made the crossover about four years ago. (Part of a general ego-reduction plan. But you know how it goes... It's easy to take it off. It's keeping it off that's the problem.)
sean@lfcs.ed.ac.uk (Sean Matthews) (05/04/89)
In article <855@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >Dr Hubert Matthews at CERNvax has privately sent me the following note. [point made in favour of Formal methods by the good Doctor (good on two counts: he shares a surname with me and he is in favour of formal methods - did you ever run into Jon by the way?)] >I do not share your faith in formal methods or methodologies. To me, >the work of programming consists of weaving order with chaos. The amount >Col. G. L. Sicherman >gls@odyssey.att.COM ^^^^^^^ I just what to clear up a point; isn't Odyssey Richard Platek's operation in Ithaca (sorry about the spelling) which specialises in mathematically verified software i.e., formal methods? Or has the good professor gone back to mathematical logic and left the field to the hackers? Se\'an
ccs013@castor.ucdavis.edu (Jason) (05/04/89)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >Real programmers spend 90% of their time debugging. Computer science >curricula ignore debugging, perhaps because it can never be reduced >to a theory. >2. The ability to "port" software. This is an acid test for distinguishing > able programmers from mere C.S. grads. >3. The ability to maintain somebody else's code. Most C.S. students have > no experience in this. and other atributes supposedly lacked by *>mere<* CS grads.... I do not mean to flame the writer of the inserted article, but..... I do not know what school you went to for your degree (or the schools of the people you hire) ....but it is unfortunate that, at that school, the CS students were taught SO poorly! Where I attend here at the University of California, Davis.... CS students FROM THE VERY START are taught the things that YOU say CS people just can't hack (no pun intended). I think that your statements were very close minded...and arrogant..... I apologize if I have offended you...but I believe an apology to those who ARE competent CS grads is due... Jason ccs013@castor.ucdavis.edu
ccs013@castor.ucdavis.edu (Jason) (05/04/89)
oh, by the by .... real CS's know software eng. AND what you boys say "programming (ers)" is (are).... JAson ccs013@csator.ucdavis.edu
hollombe@ttidca.TTI.COM (The Polymath) (05/04/89)
In article <39400019@m.cs.uiuc.edu> render@m.cs.uiuc.edu writes: }The Colonel gives a good list of skill requirements for software engineers, }but I'll be damned if I know how you can judge someone's ability on this kind }of stuff unless you've watched them do it. Debugging is something they all }should have done on programming assignments, but how do you rate debugging }skill? ... On one job interview I brought along a sample. I showed them two listings of a program I'm currently responsible for. The first was the one I got when I took over maintenance of the (extremely buggy) code. The second is what the code looks like now (bug free, as far as I know). Don't know if it helped, but they were on the point of hiring me when the job got moved from Berkeley to Boston. Oh, well. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
hollombe@ttidca.TTI.COM (The Polymath) (05/04/89)
In article <855@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: }Thanks for your note. Indeed, the programmers on my project probably }don't spend more than 50% of their time testing and debugging. It }depends on where we stand in the development cycle. Perhaps we have a semantic quibble here. The usual figure quoted is a system will spend ~70% of its life in maintenance mode. Maintenance is much more than debugging. It includes enhancement and making the program do what the customer wants it to do, after you've made it do what they asked for it to do. Given that, it's not unreasonable to expect most programmers to spend 70% of their time maintaining existing software, as opposed to creating new software from scratch. -- The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com) Illegitimati Nil Citicorp(+)TTI Carborundum 3100 Ocean Park Blvd. (213) 452-9191, x2483 Santa Monica, CA 90405 {csun|philabs|psivax}!ttidca!hollombe
cs132046@brunix (Garrett Fitzgerald) (05/04/89)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >3. The ability to maintain somebody else's code. Most C.S. students have > no experience in this. The second assignment in CS132 this year was to rewrite UNIX's file command so that it recognized Pascal. (I would advise against trying to read file.c--it could be hazardous to your health!) >[The ability to work from specs] That was another of our assignments--we had to write our own specs for a "Breakout" program, but then we had to code the specs they gave us. >6. The ability to write adequate user documentation. See 4. Writing the ExDoc was a major part of our final project. >7. Experience with a variety of languages, environments, and methods. One of the few failings of the department here. We do almost all of our programming assignments on Suns, with various different interfaces for the different courses. CS132 (Intro to S.E.) uses X, CS4 uses an environment called Passe`, CS12 uses yet another...If we ever have to deal with MS-DOS and PC-XT's, we could be in trouble... -------------------------------- Campus Crusade for Cthulhu--when you're tired of the lesser of two evils. Sarek of Vulcan, a.k.a. Garrett Fitzgerald cs132046@brunix or st902620@brownvm.bitnet
db@lfcs.ed.ac.uk (Dave Berry) (05/05/89)
In article <42fba1e1.183dc@apollo.COM> perry@apollo.COM (Jim Perry) writes: > >Unfortunately I believe real debugging skills can only acquired with >experience. You can teach techniques for writing relatively bug-free >code, the hard part is when you have to debug someone else's code (or >spec/interface, whatever). I read several books and articles on debugging as background for my thesis. I would recommend "Debugging C", by Robert Ward, published by Que corporation. ALthough it focuses on C on micros without sophisticated environments, Ward has enough useful ideas of a general nature to make this worth reading by people learning to program in most languages and environments. Ward does some teaching, and does teach people how to debug. He claims that his best pupils are those who can both design well and debug well. "You never smile, you know it wouldn't look right. 'Cause your dentures glow in ultra-violet light..." Dave Berry, Laboratory for Foundations db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk of Computer Science, Edinburgh Uni. <Atlantic Ocean>!mcvax!ukc!lfcs!db
gls@genesis.ATT.COM (g.l.sicherman) (05/06/89)
In article <1916@etive.ed.ac.uk>, sean@lfcs.ed.ac.uk (Sean Matthews) writes: < I do not share your faith in formal methods or methodologies. To me, < the work of programming consists of weaving order with chaos. ... < --gls@odyssey.att.COM > > I just what to clear up a point; isn't Odyssey Richard Platek's operation > in Ithaca (sorry about the spelling) which specialises in mathematically > verified software i.e., formal methods? Ha! I suppose this comes of abandoning the flat namespace. The "odyssey" I post from is a macromini used for routine software development. By the way, we have plenty of bugfree environments here at AT&T, mostly in telephone switching systems where the least bug is a disaster in the field. When you have to be that careful, productivity runs in tens of lines per month. As you can see from Jim Perry's story, a programming environment works very well if each programmer takes *complete* responsibility for her programs. I'm not against formal methods, either--so long as you don't rely on them! GIGO applies to programmers as well as data; good programmers feed themselves into their programs. -:- "Hey, Rocky! Watch me pull a UNIX program out of my source directory!" "AGAIN?" "Nothin' up my sleeve ... PRESTO!" IDENTIFICATION DIVISION. PROGRAM-ID. PROCESS-DATA. AUTHOR-NAME. B. T. MOOSE, FROSTBYTE DATA SYS. SOURCE-COMPUTER. IBM-7044. OBJECT-COMPUTER. IBM-7044. . . . "No doubt about it--I gotta get a new source directory!" -- G. L. Sicherman gls@odyssey.att.COM
warren@jove.cs.pdx.edu (Warren Harrison) (05/06/89)
Sure software engineers spend a great deal of their time debugging,
coding, designing, etc. I think many of us are missing one VERY
important activity (that software engineers COULD be prepared for
in school) --- communicating. I find that many of my students (and
many new programmers/software engineers I have worked with) have a
very difficult time of communicating with others, both orally and
in writing. In most of the projects I have been involved in, this
skill was almost as important as programming since you always end up
describing the system or the code or whatever to others.
I don't necessarily mean you have to be able to write the great
American novel, but when you get up in front of the other 20
people on the project and try and explain your part of the system
(or worse yet, the system as a whole) and can't (or worse yet
describe the *wrong* interface) you're in trouble.
Most posters seem to do a pretty good job of it. Maybe if I require
my students to post 3 messages to the net each term they'll improve???
Warren
Warren Harrison CSNET: warren@pdx.edu
Department of Computer Science UUCP: {ucbvax,decvax}!tektronix!psu-cs!warren
Portland State University Internet: warren%pdx.edu@relay.cs.net
Portland, OR 97207-0751emuleomo@yes.rutgers.edu (Emuleomo) (05/07/89)
> Real programmers spend 90% of their time debugging. Computer science > curricula ignore debugging, perhaps because it can never be reduced > to a theory. But debugging skills are what I would look for *first.* > (By the way, I am using "software engineer" as synonymous with "programmer." > Separating design from implementation is usually a mistake; ask the DoD.) I must say that debugging skills, although important, are NOT AS IMPORTANT AS GOOD **SOFTWARE DESIGN** skills. In general, the amount of time required to debug a program, is INVERSELY PROPORTIONAL to the amount of time spent on the drawing board designing the program properly. Have you ever seen a civil engineer debugging a bridge after it has been built? Give me a disciplined designer anyday. Debugging is usually the result of haphazard work. -- Emuleomo O.O. ** Writing good, clean code is pure MAGIC. That's why it's so hard to do! **
render@m.cs.uiuc.edu (05/08/89)
Written 8:33 pm May 5, 1989 by warren@jove.cs.pdx.edu: >Sure software engineers spend a great deal of their time debugging, >coding, designing, etc. I think many of us are missing one VERY >important activity (that software engineers COULD be prepared for >in school) --- communicating. I find that many of my students (and >many new programmers/software engineers I have worked with) have a >very difficult time of communicating with others, both orally and >in writing. When I was an undergrad in CS, we were required to take at least two "communications" courses. They could be either public-speaking or rhetoric. They turned out to be among the most useful things I have studied with respect to application in later life. I've always thought that engineers in general have poor writing and speaking skills and should have higher expectations thrust upon them. As an aside, we were also required to take two management courses, something I have found very helpful in life but fairly uncommon in CS curricula. Hal Render render@cs.uiuc.edu
diamond@diamond.csl.sony.junet (Norman Diamond) (05/08/89)
In article <May.6.16.52.43.1989.2510@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >Have you ever seen a civil engineer debugging a bridge after it has been built? I haven't personally seen a civil engineer work. However, I have read newspaper articles about bridges and various other structures that needed debugging after being built, that were debugged before being re-built, after falling apart. The real question is, why does it happen less often with bridges than with programs? Two answers that I know: 1. Engineering companies, government institutions, etc., generally have a better feel for the difficulties of other fields of engineering. They generally allow enough time for designs to be completed properly, and they occasionally reward good work instead of criticizing it. 2. There are fewer bridges than there are programs. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net) The above opinions are my own. | Why are programmers criticized for If they're also your opinions, | re-inventing the wheel, when car you're infringing my copyright. | manufacturers are praised for it?
cliff@ficc.uu.net (cliff click) (05/08/89)
In article <4642@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: > People who call themselves "software engineers" usually can't program > worth squat. I've produced 30000 to 35000 lines of code/year for the past 3 years that end up in income-producing products. I consider myself BOTH a programmer AND a Software Engineer. "People who post blanket statements should be Shot!" - me -- Cliff Click, Software Contractor at Large Business: uunet.uu.net!ficc!cliff, cliff@ficc.uu.net, +1 713 274 5368 (w). Disclaimer: lost in the vortices of nilspace... +1 713 568 3460 (h).
smiller@umn-cs.CS.UMN.EDU (Steven M. Miller) (05/09/89)
> In article <May.6.16.52.43.1989.2510@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: > > >Have you ever seen a civil engineer debugging a bridge after it has been built? > Sure. the brand new bridge in St. Paul MN over the Mississippi just buckled. The temporary solution was to put a bunch of concrete barriers on the bridge to push the buckled part back in line. Permanent solution is now being worked on. Or how about the freeway segment in my hometown that has a stoplight because the design accidentally had to off/on ramps connecting with one another? I'm sure there are hundreds of civil engineering projects that need or needed debugging. Software can be orders of magnitude more complex and commonly has to run on multiple hardware platforms. You're comparision seems to be between apples and oranges. -Steve -- -Steve Miller, U of MN
djones@megatest.UUCP (Dave Jones) (05/09/89)
From article <1146@psueea.UUCP>, by warren@jove.cs.pdx.edu (Warren Harrison): ... > I think many of us are missing one VERY > important activity (that software engineers COULD be prepared for > in school) --- communicating. > ... I did a two year stint as a visiting associate professor at a university in Ohio. When I told my students that communication skills were very important to programmers, they just flat out didn't believe me. I discovered that very few even owned a dictionary. So, I told them I would give the equivalent of a quiz grade of 100 to every student who would bring a dictionary to class. Only one student out of two sections brought in the book. A friend of mine who also taught there told me that if I didn't want to get into trouble, I better not do that again. Only the textbook committee could make requirements about which books students are required to have, he said.
jwb@LINDENTHAL.CAE.RI.CMU.EDU (John Baugh) (05/09/89)
In article <12701@umn-cs.CS.UMN.EDU> smiller@umn-cs.CS.UMN.EDU (Steven M. Miller) writes: >Software can be orders of magnitude more complex and commonly has to run on ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >multiple hardware platforms. You're comparision seems to be between As a once-practicing civil engineer, all I can say is `baloney'. (BTW, I have also worked on software projects of > 100,000 lines of Fortrash, so I at least have some experience on both sides.) Visit your friendly neighborhood consulting AE firm to get an idea of the number of people, specifications/requirements, etc. that must be coordinated in the design and construction of a real engineering product -- it's staggering. John Baugh --
rja@edison.GE.COM (rja) (05/09/89)
In article <4167@ucdavis.ucdavis.edu>, ccs013@castor.ucdavis.edu (Jason) writes: > and other atributes supposedly lacked by *>mere<* CS grads.... > > I do not mean to flame the writer of the inserted article, but..... > Nonsense. You read the article with a chip on your shoulder. Being a software engineer isn't a function of what the piece of paper says or the name of the department is. Here we have many software engineers and the degrees include EE, Physics, Math, CS, ... Now I think that the distinction between software engineers and programmers varies a lot because neither term is well-defined, but the posting made its terms reasonably clear.
shebs@Apple.COM (Stanley Todd Shebs) (05/10/89)
In article <4951@pt.cs.cmu.edu> jwb@LINDENTHAL.CAE.RI.CMU.EDU (John Baugh) writes: >In article <12701@umn-cs.CS.UMN.EDU> smiller@umn-cs.CS.UMN.EDU >(Steven M. Miller) writes: >>Software can be orders of magnitude more complex [...] > >As a once-practicing civil engineer, all I can say is `baloney'. >(BTW, I have also worked on software projects of > 100,000 lines >of Fortrash, so I at least have some experience on both sides.) >Visit your friendly neighborhood consulting AE firm to get an >idea of the number of people, specifications/requirements, etc. >that must be coordinated in the design and construction of a real >engineering product -- it's staggering. Comparing numbers of people or pounds of documentation is not necessarily valid. My personal impression from working alongside assorted engineers is that individuals tend to be more specialized in the traditional engineering disciplines. So for instance you might have somebody on a project that is concerned only with bolts, or electrical connectors, or maybe even with only a single oddly-shaped part made by a subcontractor. Many (most?) software people are in the opposite situation - they have to be concerned about all aspects of a 50K line program, and they rarely have the leisure to really understand the code proper, the design, the limitations, the consequences for other parts of a system, and so forth. Just imagine how different things would be if you only had to be responsible for, say, 1,000 lines of code and could spend a year working on it. You spend time analyzing it in depth, you could polish the documentation, you could tune it for optimum performance. Unfortunately such a situation is rarely possible in today's environment... Getting back to comparing bridges and programs, a more valid method might be to compare the information content of a program to that of a bridge (more accurately, to the size of its description). This would factor out sheer volume; 10,000 identical bolts aren't much more interesting than one bolt, ditto for code that is replicated in different parts of a program. Seems like at least one theorist would have looked at this in the past... stan shebs shebs@apple.com
djones@megatest.UUCP (Dave Jones) (05/10/89)
From article <4105@ficc.uu.net>, by cliff@ficc.uu.net (cliff click): > In article <4642@goofy.megatest.UUCP>, djones@megatest.UUCP (Dave Jones) writes: >> People who call themselves "software engineers" usually can't program >> worth squat. > I've produced 30000 to 35000 lines of code/year for the past 3 years that end > up in income-producing products. Wow. Fifteen lines an hour, eight hours a day, 250 days a year. Love those keyboard macros! :-) > I consider myself BOTH a programmer AND a Software Engineer. > These days, everybody's got to have a slash. Me? I'm a programmer- slash-wizard. But then there's a fellow here who, reversing the trend, just calls himself a "simple country programmer". > > "People who post blanket statements should be Shot!" - me > I confess that the irony in the above escaped me on first reading. But be fair! My blanket had a "usually"-hole in it. Besides, how do you know I'm not already shot?
schow@leibniz.uucp (Stanley Chow) (05/10/89)
In article <1736@internal.Apple.COM> shebs@Apple.COM (Stanley Todd Shebs) writes: > >Comparing numbers of people or pounds of documentation is not necessarily >valid. My personal impression from working alongside assorted engineers >is that individuals tend to be more specialized in the traditional engineering >disciplines. [...] Perhaps this is why engineer build bridges that work better than most programs! There may be a lession for budding software engineers. > [...] So for instance you might have somebody on a project that is >concerned only with bolts, or electrical connectors, or maybe even with only >a single oddly-shaped part made by a subcontractor. Many (most?) software >people are in the opposite situation - they have to be concerned about all >aspects of a 50K line program, and they rarely have the leisure to really >understand the code proper, the design, the limitations, the consequences >for other parts of a system, and so forth. [...] I would consider 50K lines to be a (very) small part of a big software systen or project. (No smiley). If one person cannot totally comprehand a small program like that, either the person or the method ought to be examined carefully. As I understand "software engineering", a good part of the effort is devoted to making systems modular and understandable. One may disagree with the specific approach - Ada, Modula-2, C++, etc., but the aim is valid. In big systems, even in small 50KLOC programs, it is important to partition the program into understandable chunks. S/W people call this module interface. The civil/mechanical engineers call this "specification". It would be nice if the mechanical engineer understood how stainless steel is made and what interesting reactions corode different steel, but it is not necessary to build a bridge. There are standards that gurantee N years of corodesion resistance as long as the exposure to corosive chemicals are within certain specific limits. The S/W analogy is like the mathmatics libraries. If you call this matrix inversion routine, you will get back a good inverse as long as the input matrix is not singular, etc. May be the answer is a mandotary course in "standard writing" for all software enginees. As someone said, "Software will be a science when programmers stand on each other's shoulders instead of each other's toes." [I would be grateful if someone can point to the originator of this] > [...] Just imagine how different things >would be if you only had to be responsible for, say, 1,000 lines of code and >could spend a year working on it. You spend time analyzing it in depth, you >could polish the documentation, you could tune it for optimum performance. >Unfortunately such a situation is rarely possible in today's environment... > Aside from a quibble with your scale, I agree with your goal. However, I like to think that some, if not most, software projects are run better than you make it out to be. If the situation is indeed as bleak as you say, then I would worry about the future of S/W, especially in the USA or North America. >Getting back to comparing bridges and programs, a more valid method might be >to compare the information content of a program to that of a bridge (more >accurately, to the size of its description). This would factor out sheer >volume; 10,000 identical bolts aren't much more interesting than one bolt, >ditto for code that is replicated in different parts of a program. Seems >like at least one theorist would have looked at this in the past... > > stan shebs > shebs@apple.com This is a subject that has interested me over the years. Let's say I make a copy of a matrix addition routine, change it to do subtraction, how much information have I added? What metrics can we use? Is it possible to determine which programs are copies of each other? Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public I am just a small cog in a big machine. I don't represent nobody.
piet@cs.ruu.nl (Piet van Oostrum) (05/10/89)
In article <12701@umn-cs.CS.UMN.EDU>, smiller@umn-cs (Steven M. Miller) writes: `> In article <May.6.16.52.43.1989.2510@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: `> `> >Have you ever seen a civil engineer debugging a bridge after it has been built? `> ` `Sure. the brand new bridge in St. Paul MN over the Mississippi just `buckled. The temporary solution was to put a bunch of concrete barriers on `the bridge to push the buckled part back in line. Permanent solution is `now being worked on. ` Some time ago there was a CACM article about the design of bridges (CACM April 1986). It mentioned a few cases of bridges that collapsed during or shortly after the construction. -- Piet van Oostrum, Dept of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Telephone: +31-30-531806. piet@cs.ruu.nl (mcvax!hp4nl!ruuinf!piet)
shebs@Apple.COM (Stanley Todd Shebs) (05/11/89)
In article <493@bnr-fos.UUCP> schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) writes: >I would consider 50K lines to be a (very) small part of a big software systen >or project. (No smiley). If one person cannot totally comprehand a small program >like that, either the person or the method ought to be examined carefully. 50K lines *per person* is an approximation I picked based on observations in several different industries over the past few years. I'm assuming relatively sparse commentary, as seems to be the norm (sigh) - heavily commented code might be 2-3 times longer. Note also, "total comprehension" is pretty extreme. It means for instance that somebody could pick any single line and you would be able to justify its existence, explain why alternatives were not used, mention how it relates to the specification, and comment on the consequences of changing it in various ways. Total comprehension is actually somewhat rare, since it is possible to write and even debug software without understanding it completely. Incidentally, the "50K lines == small" statement is a familiar one, but I've not seen any reliable and up-to-date statistics on program sizes. Is there a believable chart anywhere of sizes, numbers, and the numbers of people involved? >In big systems, even in small 50KLOC programs, it is important to partition the >program into understandable chunks. S/W people call this module interface. The >civil/mechanical engineers call this "specification". Only amateur programmers and researchers work without specifications these days. The issues revolve around how formal the specifications can be. Informal specifications seem to cause as much difficulty as they resolve, while formal specifications are fantastically hard to get right. >May be the answer is a mandotary course in "standard writing" for all >software enginees. Undergraduate software engineering classes feature the writing of interface specs, but the environment is too artificial to get students to feel a realistic level of pain at having to conform to a bad specification. Classes can't always substitute for experience... >[...] I like >to think that some, if not most, software projects are run better than you >make it out to be. If the situation is indeed as bleak as you say, then I >would worry about the future of S/W, especially in the USA or North America. I always have an eye out for the well-run software project, but a little digging generally reveals that much of the proper methodology is window dressing, concealing the programmers-who-despise-software-engineers who are cranking out miles of code. I've been observing this ever since my first software job, which involved writing documentation for an entirely comment-free Fortran program, to make it appear as if it had been constructed according to the DoD's standards for delivered software... stan shebs shebs@apple.com (What about Apple? Well, I'll have to dig around and get back to y'all on Apple's software engineering standards)
heberlei@iris.ucdavis.edu (Todd) (05/11/89)
[Jason's (from UCD) ranting and raving] Whoa! Jason, unless you are planning on working completely by yourself for the rest of your life, you better learn to treat other people with a little more respect. Almost any project you work on will require the cooperation of a number of people from different disciplines: tech writers, programmers, managers, engineers of all types, etc. (Please note that this implies communication skills are very important) I did my undergraduate work in CS at UC Davis, have worked for our Division of Computer Science for the past year, and will return next year as a grad student in CS here at UC Davis (hey, I like it here :-) I have also worked for our Physics Dept (and taken Physics 104,105,110) and our Engineering Dept., and I find Jason's statements completely unfounded. I hope everyone out in net-land realizes Jason's views are his own; our Division of Computer Science is a great place to be (we are nice people). I agree to some extent with Jason's fear of money getting in they way of "pure science." When I was shopping for grad schools, I was upset to see schools offering an MBA with their CS degrees. However, if you want to be a key component in a research organization, you do need to have both good managerial and economic skills. Also, if an engineer does have a desire to make lots of money (nothing wrong with that), he/she is going to have to be one of the better ones in their field. The result: they learn the material anyways. :-) Enough dribble! ------------------- some thought to ponder on ----------------------- * We have been building bridges for a lot longer than we have been programming computers. Programming/SE is a trade in its infancy; maybe after a few thousand years we will be doing things correctly the first time. * I recall hearing about lots of engineering flaws in complex systems such as autos, planes, space shuttles, etc. One of Edwards AFB's primary goals was/is to debug new plane designs. I think a "prototype" really means they are trying to debug something. :-) Debugging is not the sole property of software development. * Since patching a program is easier than retooling a machine or fixing a support in a tall building (short ones too :-), maybe we software writers (and SEs) are less worried about getting something perfectly right the first time. Enough already. Send complaints to /dev/null. Todd Heberlein heberlei@leek.ucdavis.edu 128.120.57.26 heberlei@iris.ucdavis.edu 128.120.57.20
periklis@ecrcvax.UUCP (Periklis Tsahageas) (05/11/89)
In article <854@odyssey.ATT.COM> gls@odyssey.ATT.COM (g.l.sicherman) writes: >Real programmers spend 90% of their time debugging. Computer science >curricula ignore debugging, perhaps because it can never be reduced >to a theory. In article <42fba1e1.183dc@apollo.COM> perry@apollo.COM (Jim Perry) writes: >Unfortunately I believe real debugging skills can only acquired with >experience. I find it hard to believe that there exists a single Computer Science (or Software Engineering for that matter) curriculum that ignores debugging. I will use the term debugging as the process of : 1. Testing a [piece | system] of software 2. Identifying parts of its behaviour which [are not in | differ from] its specs 3. Identifying the changes that have to be made in the code (or, in the unfortunate case, in the specification) and 4. Doing these changes. In the first year of our Software Engineering degree, in the programming course, we had a series of lectures on testing. Some theoretical foundations for testing were laid then. Examples I recall AND USE : I. Test harnesses (e.g. to test ADTs, write a simple menu-driven program which performs operations on objects of the ADT and displays the results) II. Test stubs (e.g. to test a complex program, write dummy versions of the procedures it calls (and ADTs it uses) and test it with them) It's obvious that the above correspond to bottom-up and top-down design. There is no reason, however, that they can not be combined. Task 2 does not seem trivial but, again, I will argue that there are theoretical foundations here as well. Consider, for argument's sake, the testing of a procedure which performs some manipulation on lists. Its spec will have been written based on the definition of a list (well known, I presume, to all programmers and S.E.s reading this :-)). It follows that the test cases tried using (I) will include at least one empty and some non-empty lists. The differences between specs and functionality of the implementation will, thus, be easily located. For task 3 you are not on your own : complete specifications, written by an appropriate method, careful, modular, DOCUMENTED design (and experience) will be your best friends. Note that this is a task equivalent to coding. Assuming, however, that a good design will, probably, mirror the specs, it shouldn't be difficult to pinpoint the erroneous parts of the code. According to taste, you might want to use a debugging tool. Personnaly, I think that debuggers are usefull only for discovering bugs in other people's code. Our college's curriculum didn't ignore this subject either. In the second year, the theoretical foundations were laid for writting specifications and design. During the whole degree, programming exercises cover a broad range of languages, compilers, operating systems and computers. I would find it highly unlikely for someone to tackle these (especially the first ones) without making any errors. As for task 4, as nick@hp-sdd.hp.com.UUCP (Nick Flor) put it, in article <1985@hp-sdd.hp.com> : >Real programmers use only one CASE tool: vi. Real software engineers, however, wouldn't dream of starting a project without, at least, something with the functionality of [SC|R]CS. A final note, just to stir things up : SOME programmers have a very clever way of reducing the time spent debugging : They don't write specs :-). This makes task 2 trivial ! -- Periklis Andreas Tsahageas European Computer-Industry Research Centre Arabellastrasse 17, D-8000 Muenchen 81, West Germany +49 (89) 92 69 91 09 USA: periklis%ecrcvax.uucp@pyramid.pyramid.com ...!pyramid!ecrcvax!periklis Europe: periklis@ecrcvax.uucp ...!unido!ecrcvax!periklis
paul@moncam.co.uk (Paul Hudson) (05/11/89)
There is a difference between civil engineering projects like bridge building and large programming projects. Even though the bridge may fail, when it does it's regarded as the fault of the civil engineer, and contracts often specify that any fixing of failures should be paid for by the civil engineer, and even that other financial consequences of the failure such as damages should also be the responisbility. This works because the likelihod of failure is reasonably low. Contrast this with a software project. Not only do many fail (most? according to a previous posting), but the suppliers oftne do not guarantee it's continued operation and charge "maintenance" for fixing bugs and errors in the programs. The aim of software engineering (and formal methods) as I see it is to reduce the chance of failure to the point where a software company can guarantee it's product will work according to the spec. and if it doesn't fixes are included in the contract price, such price to be roughly in line with current prices, and below current prices + projected maintenance costs. Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket" -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"
raveling@venera.isi.edu (Paul Raveling) (05/13/89)
In article <4625@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >From article <854@odyssey.ATT.COM>, by gls@odyssey.ATT.COM (g.l.sicherman): > >> Real programmers spend 90% of their time debugging. > > >Gack!! The mind boggles. It sure does! It's much easier to just not go to the effort of putting bugs into programs in the first place. Actually, the numbers I thought were generally accepted were 20% - 50% of project time for debugging. ---------------- Paul Raveling Raveling@isi.edu P.S.: If this seems a bit stale, or you're at ISI and it's a duplicate, that's because our newsfeed went read-only for a week or two. This is a repost of something that I believe didn't get out.
raveling@venera.isi.edu (Paul Raveling) (05/13/89)
In article <743@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: > >Nonsense. "Software engineer" is not synonymous with "programmer". One of >the differences between a software engineer and a programmer is that, while >a programmer probably does spend 90% of his time debugging, a software >engineer spends, maybe, 25% of his time debugging. ... From what I've seen of both "programmers" and "software engineers", I'm inclined to think the distinction is more like the difference between a "garbage collector" and a "sanitation engineer". They do the same things in substantially the same ways, but one name sounds more impressive. Remember when "programmers" were the elite and "coders" were the ones with less status? ---------------- Paul Raveling Raveling@isi.edu P.S.: If this seems a bit stale, or you're at ISI and it's a duplicate, that's because our newsfeed went read-only for a week or two. This is a repost of something that I believe didn't get out.
raveling@venera.isi.edu (Paul Raveling) (05/13/89)
In article <4750@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >From article <4105@ficc.uu.net>, by cliff@ficc.uu.net (cliff click): >> I've produced 30000 to 35000 lines of code/year for the past 3 years that end >> up in income-producing products. > >Wow. Fifteen lines an hour, eight hours a day, 250 days a year. Love those >keyboard macros! :-) No keyboard macros required. My numbers were about the same when being project leader, then manager, made me measure them for everyone including me. For my own numbers, median production of debugged product-quality code is around 200-300 lines per day when the day has no meetings and the project's learning curve is past history. Hacking takes this up to 700-800 lines per day, but don't expect to keep and maintain such a hack. To average over time, accounting for documentation, cummunication overhead, and such, I'd project 100 lines per day if the organization doesn't have a management muddle (most do). An exception is producing MIL-spec code and documentation. Using these standards drops my productivity in terms of lines of code by a factor of about 3-4. Doing rigorous module tests for MIL-spec work decreases the number of bugs existing at system integration by perhaps 5%. However, for MIL-spec work it may be more sensible to measure productivity by pages of documentation instead of lines of code. ---------------- Paul Raveling Raveling@isi.edu P.S.: If this seems a bit stale, or you're at ISI and it's a duplicate, that's because our newsfeed went read-only for a week or two. This is a repost of something that I believe didn't get out.
jamesg@syma.sussex.ac.uk (James S Goodlet) (05/15/89)
In article <May.6.16.52.43.1989.2510@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >Have you ever seen a civil engineer debugging a bridge after it has been built? Indeed, the Erskine bridge over the River Clyde in Glasgow (Scotland) was heavily "debugged", notably with changes to the railings at the sides of the bridge to change its behaviour in cross winds (I believe the bridge was resonating slightly). Not on bridges but related, consider the infamous M25 motorway around London, England. This was repaired (several thousand tarmac joints replaced) *before* it had even opened. And now, only a few years after it was completed, it is being extensively widened. These are real bugs. Surely the point to be made is that such bugs occur less in traditional engineering ventures since: 1) they utilise disciplines which are reasonably mature and understood - there is a science (engineering discipline if you must) in bridge building - much of it is painting by numbers now. Software coding and *design* is not understood, regardless of the claims of proponents of structured design methodologies. These methodologies serve a useful purpose in supporting the book-keeping requirements of the task - they lend nothing to the assistance of the creative effort of the design team. Thus "software engineering" is an art, not a science. 2) the designs can quite successfully be decomposed into discrete subtasks, with the overall design the remit of one or two individuals. This is in the spirit of "The Mythical Man- Month"'s pilot/copilot idea, where the design is specifically the product of one or two individuals, with other team members playing supporting roles. (This is often given as the reason for the comparative success of small software teams.) In a traditional engineering discipline, the knowledge required for the design task has been made accessible through centuries of empirical investigation and analyses of results. This knowledge can be used by (held within the mind of) one or two principal engineers on a project, thus leading to internally consistent, cohesive designs. Software design/coding is not understood and thus requires either supranormal individuals (rare - if you find one, keep him/her), or many brains together. And many brains lead to inconsistencies, and unforeseen interactions - see mediaeval cathedral construction (the exception being Rennes). James (*** please note, no offence is intended to structural/civil engineers - in order to "paint by numbers", they need to attain a high level of proficiency in an esoteric domain ***) -- School of Cognitive & Computing Sciences, Talk: +44-(0)273-806755 x2407 University of Sussex, JANET: jamesg@uk.ac.susx.cogs Brighton BN1 9QN, UUCP: ...!mcvax!ukc!cogs!jamesg United Kingdom ARPA: jamesg%cogs.susx.ac.uk@nsfnet-relay.ac.uk
rgo@berlioz (Ronald Olshausen) (05/16/89)
In article <8338@venera.isi.edu> raveling@venera.isi.edu (Paul Raveling) writes: >In article <4750@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >>From article <4105@ficc.uu.net>, by cliff@ficc.uu.net (cliff click): >>> I've produced 30000 to 35000 lines of code/year for the past 3 years that end >>> up in income-producing products. >> >>Wow. Fifteen lines an hour, eight hours a day, 250 days a year. Love those >>keyboard macros! :-) > > For my own numbers, median production of debugged product-quality > code is around 200-300 lines per day when the day has no meetings > and the project's learning curve is past history. Hacking Those figures sound very high. But really, statistics regarding Source Lines/Hour mean nothing, unless they're put in the context of what the code does. For example, writing 5000 lines of code to do real-time embedded applications could be a whole lot different than writing 5000 lines for a user-friendly terminal interface. Depending on the degree of difficulty involved, productivity, as measured in SLOC/hour, could vary by a factor of ten, or more. Ron Olshausen NSC-Santa Clara
vfm6066@dsacg3.UUCP (John A. Ebersold) (05/16/89)
In article <990@syma.sussex.ac.uk> jamesg@syma.sussex.ac.uk (James S Goodlet) writes: >Surely the point to be made is that such bugs occur less in traditional >engineering ventures since: > >1) they utilise disciplines which are reasonably mature and understood - > >2) the designs can quite successfully be decomposed into discrete > subtasks, with the overall design the remit of one or two > individuals. This is in the spirit of "The Mythical Man- > Month"'s pilot/copilot idea, > Software design/coding is not understood and > thus requires either supranormal individuals (rare - if you find > one, keep him/her), or many brains together. And many brains > lead to inconsistencies, and unforeseen interactions - see > mediaeval cathedral construction (the exception being Rennes). In an article titled (I believe) "Slaying the software beast" (No silver bullet) in IEEE Computer, Frederick Brooks wrote about the sad state of software development. Recommend reading. He concluded, as you do, one solution seems to be finding and developing excellent software designers. These people should be given status and perks that high level management is typically given. After reading that article last year and thinking about software that seems to have been done right, leading projects small and large (some of which have turned out better than others) I have reached the conclusion that every project needs a design (and perhaps requirements) dictator. This person should be the best designer in the organization and is not neccessarily the project leader but it would help if she/he were. As Brooks wrote, to paraphrase, The best designers are not always the most experienced. The dictator should have a overall vision of what the software must do and the best way to do it. This is not to say that design trade-offs are not discussed with other project members, but when a decision must be made, the dictator decides. On a related subject... I believe that setting out general design and documentation principles and getting the partitioning bewteen the major portions of a system "right" are the most important things one can do as a project leader. I would make sure similar things are designed in a similar manner (and perhaps generalized) rather than concentrating on the design of some modules that is only needed in one place. Leave those things to other team members. What do you all think? As if I had to ask :-). -- John A. Ebersold at Defense Logistics Agency osu-cis!dsacg1!dsacg3!vfm6066 Unify Corporation System Automation Center Columbus, Ohio 1-614-238-5923 AV 850-5923 Systems with poorly understood requirements cannot be developed in a crunch.
shapiro@rb-dc1.UUCP (Mike Shapiro) (05/18/89)
In article <12701@umn-cs.CS.UMN.EDU> smiller@umn-cs.CS.UMN.EDU (Steven M. Miller) writes: ... >Software can be orders of magnitude more complex and commonly has to run on >multiple hardware platforms. You're comparision seems to be between >apples and oranges. More like grapes and watermelons, I think (or something similar). (I'm not sure the order of magnitude analogies of software vs. bridges over rivers, but apples and oranges seem too close in size.) -- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1
conor@inmos.co.uk (Conor O'Neill) (05/18/89)
In article <990@syma.sussex.ac.uk> jamesg@syma.sussex.ac.uk (James S Goodlet) writes: >In article <May.6.16.52.43.1989.2510@yes.rutgers.edu> emuleomo@yes.rutgers.edu (Emuleomo) writes: >>Have you ever seen a civil engineer debugging a bridge after it has been built? > >Indeed, the Erskine bridge over the River Clyde in Glasgow (Scotland) >was heavily "debugged", notably with changes to the railings at the >sides of the bridge to change its behaviour in cross winds (I believe >the bridge was resonating slightly). > >Not on bridges but related, consider the infamous M25 motorway around >London, England. This was repaired (several thousand tarmac joints >replaced) *before* it had even opened. And now, only a few years after >it was completed, it is being extensively widened. These are real bugs. This reminds me of the idea of asking someone to Beta-test a Jumbo jet! to beat the line munger.... -- Conor O'Neill, Software Group, INMOS Ltd. JANET: conor@inmos.co.uk Disclaimer: All views are my own, UUCP: uunet!inmos-c!conor not those of INMOS. INTERNET: @col.hp.com:conor@inmos-c
ben@vmsa.technion.ac.IL (Ben Pashkoff) (05/30/89)
In article <1492@dsacg3.UUCP>, vfm6066@dsacg3.UUCP (John A. Ebersold) writes: > In article <990@syma.sussex.ac.uk> jamesg@syma.sussex.ac.uk (James S Goodlet) writes: > > After reading that article last year and thinking about software that seems > to have been done right, leading projects small and large (some of which > have turned out better than others) I have reached the conclusion that every > project needs a design (and perhaps requirements) dictator. This person > should be the best designer in the organization and is not neccessarily the > project leader but it would help if she/he were. > > The dictator should have a overall vision of what the software must do and > the best way to do it. This is not to say that design trade-offs are not > discussed with other project members, but when a decision must be made, the > dictator decides. > I had written a really nice commentary to this and then the machine went and digested it, so, I will summarize. In the book, In Search of Excellence, Peters and Waterman state some very important ideas for what a good company should operate by. I thnk it is all very applicable to this disscussion. In particular numbers 6 and 7, dealing with sticking to the customer, in our case the end-user, and support for a 'local champion'. I like their term better for psychological reasons. They break down the 'champion' into a 'product champion', an 'executive champion' ,and the 'godfather. Concerning the product champion they write, "the zealot or fanatic in the ranks whom we have described as being not a typical administartive type. On the contrary, he is apt to be a loner, egotistical and cranky. But he believes in the product..." Does this sound familiar? -- ___________________________________________________________________________ | | | Ben Pashkoff BEN@VMSA.TECHNION.AC.IL | | BEN@TECHMAX.BITNET | | BEN@TECHUNIX.BITNET | | VAX/VMS Systems APLBENJ@TECHNION.BITNET | | Computer Center VMSA::BEN | | Technion IIT | | Haifa, Israel 32000 Phone:(972)-4-292176 | |_________________________________________________________________________|