Re: Software Engineering Education

Re: Software Engineering Education

[spool.mu.edu!caen!zaphod.mps.ohio-state.edu!rpi!bu.edu!m2c!risky.ecs.umas]

In article <1991Jul3.233045.11174@netcom.COM> jls@netcom.COM (Jim Showalter) wr
ites:
[proposes removing General Education from the curriculum as a way to
make room for more software engineering -- including the standard "if
I'm not interested, why should I take it" speech]

If you wish to be a code-droid then by all means get a programming
degree.  If you want to be an engineer then you will require the
skills of critical analysis that the study of english can teach; the
understanding of human behavior that psychology can teach; the
understanding of creativity that art can teach; ...

That said, it is true that a interested student will take courses even
when they are not required, and an uninterested one won't get anything
out of required ones.  Maybe we should require interest instead of
courses :-)
--
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ WISE@CS.UMASS.EDU /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\

Re: Software Engineering Education

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!zaphod.mps.ohio-state.edu!wu]

OK, I'm in on this too, with two points to make:

1) As far as general distribution classes go, if you want a programming degree
without them there are lots of by-mail companies that offer degrees, as well
as lots of Institutes (ITT Technical Institute is one we always see advertised
here in Florida) that will give you training in computer programming without
all the excess. Universities are educational institutions trying to turn out
educated people. If I had it to do over again (even though I'm not quite done
yet), I would still want to take all those "extras" just for the information.
Besides, how do you know what kinds of programs you want to write if you don't
have any idea about other fields? A good deal of computer programming is for
non-computer areas (MIS, for one...). Without a background in that area, how
can you really program for it?

2) Teaching Software Engineering Concepts in classes: I think the greatest
hindrance to this is that students are taking several classes at once, and
many are working to help pay for school (me, for one). Students simply don't
have the time to do the kind of major projects that allow the teaching and
experience of what has been called "macro-SE" here. One way that USF does get
this to some students is by allowing some undergraduates to get in on research
projects. In this way, the undergraduate gets a part-time job working in with
other programmers, an experience that naturally teaches much about SE (as well
as a good deal about whatever the research project is on). Maybe if more of
these kinds of positions were offered, more undergraduates will get that
experience. But, if an undergraduate has to work a non-computer job, that
student will be scrimping for time, and is forced to throw a program together
in a few hours for a class to get it in on time.
    But, the "micro-SE" is fairly easy to integrate into classes, and has been
in every class I've taken so far.

-- Greg Stelmack (stelmack@sol.csee.usf.edu)

D
D
D
D
D
projects. 

Re: Software Engineering Education

[Orville R. Weyrich]

In article <1505@screamer.csee.usf.edu> stelmack@screamer.csee.usf.edu (Gregory
 M. Stelmack) writes:
>
>2) Teaching Software Engineering Concepts in classes: I think the greatest
>hindrance to this is that students are taking several classes at once, and
>many are working to help pay for school (me, for one). Students simply don't
>have the time to do the kind of major projects that allow the teaching and
>experience of what has been called "macro-SE" here. One way that USF does get

What you are really saying is that your school has not designed their
curriculum to support macro-SE. It would be terribly burdensome on the
students if each professor "got the religion" and decided to put a good
macro-SE experience into his/her courses. The proper way to do this is to
pick out some REQUIRED course or course sequence and to put the macro-SE
into that course (sequence) ONLY. And warn the students that they should not
expect to take 3 programming courses concurrently with that course (sequence).
All this requires planning at the department level, and coordination of the
implementation.

>this to some students is by allowing some undergraduates to get in on research
>projects. In this way, the undergraduate gets a part-time job working in with
>other programmers, an experience that naturally teaches much about SE (as well
>as a good deal about whatever the research project is on). Maybe if more of
>these kinds of positions were offered, more undergraduates will get that
>experience. But, if an undergraduate has to work a non-computer job, that
>student will be scrimping for time, and is forced to throw a program together
>in a few hours for a class to get it in on time.

While a curriculum committee should take student convenience into account,
there is a definite limit to how much the program should be compromised to
accomodate students' work schedules. The program should be designed to 
provide a full-time student [without distractions] a quality education in
4 years. Those students that have distractions should expect to have to 
reduce their course load and take longer.



--------------------------------------           ******************************
Orville R. Weyrich, Jr., Ph.D.                   Certified Systems Professional
Internet: orville%weyrich@uunet.uu.net             Weyrich Computer Consulting
Voice:    (602) 391-0821                         POB 5782, Scottsdale, AZ 85261
Fax:      (602) 391-0023                              (Yes! I'm available)
--------------------------------------           ******************************

Re: Software Engineering Education

[Dana Newman]

In article <20600125@inmet>, ryer@inmet.camb.inmet.com writes...
> 
>I was talking with a co-worker about Software Engineering Education, and said:
>   "The best thing universities could do would be to give F's to a few hackers
>   who wrote programs that worked perfectly but were completely unmaintainable
.
> 
>She said:
> 
>  When she was at MIT (early 80's), the grading for all exercises in all
>  computer science and software engineering courses was:
>    
>    25% - Quality (correctness) of the executable program
>    25% - Quality of the written design document
>    25% - Quality of the written test plan and procedures
>    25% - Quality of the user documentation
> 
>I thought this was the most intelligent approach I'd ever heard.  Do any
>of you educators have a better idea?  Is this done in other universities?
> 
>Mike Ryer
>Intermetrics

I am not an educator, but a student here at University of Houston (Clear Lake).
Here's the rundown on how we are evaluated for our Ada programming assignments.
(At least, for this particular instructor.  Might vary a bit for others.)

   Documentation and Design (20)      
     Algorithm Structure and Efficiency    15   
     Well Structured Output                 5    

   Well Structured Program (40)      
     Code matches algorithm                15      
     Meaningful variable names              5
     Comments                              15
     Test for input validity                5    

   Working Program (40)     
     Compiling/Linking                     10
     Running                               30 

There are generally four or five assignments per semester, and together 
they contribute around 30% of the final grade.

Re: Software Engineering Education

[Michael Feldman]

In article <20600125@inmet> ryer@inmet.camb.inmet.com writes:
>
>  When she was at MIT (early 80's), the grading for all exercises in all
>  computer science and software engineering courses was:
>    
>    25% - Quality (correctness) of the executable program
>    25% - Quality of the written design document
>    25% - Quality of the written test plan and procedures
>    25% - Quality of the user documentation
>
>I thought this was the most intelligent approach I'd ever heard.  Do any
>of you educators have a better idea?  Is this done in other universities?
>
For at least 10 years I have graded most projects using the following:

    40% correctness of executable (measured by input/output behavior)
    30% code quality and style
    30% user documentation

I have included the test plan implicitly in the 40%, because one can't
demonstrate correctness without a decent test plan.

Nearly everyone I know uses some formula roughly like this. Precisely how 
much weight to give to each factor is a matter of taste, but I like the MIT
formula and will consider switching to it. My own formula has not
included an explicit grade for test plan, but that's a good idea.

Editorial comment: The notion that, collectively, we don't teach the
right stuff is a canard, in my experience. Just because the students don't
learn it (or carry it with them to industry) doesn't mean we don't teach
it. We have observed that, in industry, when a project is under the gun,
all the platitudes about good style, test plan, documentation, etc., get
swamped by the demand to get the sucker running. Gerry Weinberg, in his
classic "The Psychology of Computer Programming", pointed this out 20
years ago. Maybe it's not true in your company, of course not...

Mike Feldman

-------------------------------------------------------------------------------
Michael B. Feldman
Visiting Professor 1991-92               Professor
Dept. of Comp. Sci. and Engrg.           Dept. of Elect. Engrg. and Comp. Sci.
University of Washington FR-35           The George Washington University
Seattle, WA 98105                        Washington, DC 20052

mfeldman@cs.washington.edu               mfeldman@seas.gwu.edu
(206) 632-3794 (voice)                   (202) 994-5253 (voice)
(206) 543-2969 (fax)                     (202) 994-5296 (fax)
-------------------------------------------------------------------------------

Re: Software Engineering Education

[cis.ohio-state.edu!udecc.engr.udayton.edu!blackbird.afit.af.mil!galaxy.af]

Well, I'm not teaching University students beginning programing.  But, I am
teaching Software Engineering to professionals as part of skills improvement.
I have a large project in the two-week Software Generation and Maintenance
course that we offer.  In that course the student team can get a max of 
15 points from correctly working (8 points) and correct styles etc (7 points).
Now this is out of a possible 100 points for the project which is 50% of the
grade for the class.  The rest of the 100 points for the project are awarded
for thinking through, defining, and implementing the strategy (process) for 
the project.

To be honest, the students have a very hard time with this.  They can easily 
see the solution to the project.  In fact, some of the student could sit 
down in one day and complete the project and have it work (these again are
two week courses).  Having them describe the approach and manage it is much,
much more difficult.

I strongly agree with the original poster.  My students would have a much 
easier time if the end goal were well engineered systems versus getting it 
to work and moving on the the next task.

Jim Cardow

Re: Software Engineering Education

[agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ca]

Most of the classes here at USF use varied methods for grading programs, but
in general a program with no comments and no structure will not get a very
high grade. Most (perhaps all) look at the code as well as the answer.

In our Intro class, the grading is much more strict (the old "teach 'em right
the first time" trick). All programs (written in Ada) must be fairly
completely commented, including variants/invariants on all loops and
pre-/post- conditions for all functions/procedures. Plus, documentation that
includes test cases must be handed in along with the programs. Any part
missing or incomplete results in a lower grade.

In our Software Engineering class, we do one big program in a group that must
be completely documented, including user's guide and all design documentation.
The code itself may or may not be graded, but the student finds out quickly
that writing well-commented, structured code makes it that much easier to
produce the required documentation.

Most other classes just look for some sort of commenting, mostly to make sure
that you really knew what you were doing when you wrote the code and didn't
just copy it from some book somewhere. That's good for us students -- we
usually spend most of the couple of weeks allowed for the assignments just
trying to get them running, and don't have time to make it look pretty. Of
course, after that Intro class, habit forces the code that does get written to
look pretty good the first time.

-- Greg Stelmack (stelmack@eggo.csee.usf.edu)

Re: Software Engineering Education

[Gregory Aharonian]

     The various suggestions for how to grade software products, while nice,
don't reflect that in the real world of deadlines and tight budgets, one
rarely has the luxury (or the ability to plead for cost over-runs) to do
software nicely in the software engineering sense.
     Languages like C/++ are frequently chosen in the real world for products
because it is easier to write 'bad' programs in the required time with C than
it is to a write the same program 'badly' in Ada.  There is a program I now
use on my PC, GeoWorks, that is a simple, decently implemented of what
Windows should be.  The program has received much praise.  From what I know,
the program is written mostly in assembler, with some C.  I doubt highly,
given the time, budget, and memory constraints, that this program could have
been written in Ada, and if the source code was evaluated by the proposed
academic criteria, probably would not receive a good grade. Yet the product,
albeit with annoying bugs, is a good product.
     The question should be how much of the real world show students be
taught about?  It is beneficial to teach them to program in a way that is
possible only at the few companies in the real world lucky or smart enough
to have great software development environments?

Greg Aharonian
Source Translation & Optimization

Re: Software Engineering Education

[Bill Yow]

In article <SRCTRAN.91Nov16120253@world.std.com>, srctran@world.std.com (Gregor
y Aharonian) writes:
|> 
|>      The various suggestions for how to grade software products, while nice,
|> don't reflect that in the real world of deadlines and tight budgets, one
|> rarely has the luxury (or the ability to plead for cost over-runs) to do
|> software nicely in the software engineering sense.

Of course this is great as long as you never have to maintain the code.


|>      Languages like C/++ are frequently chosen in the real world for product
s
|> because it is easier to write 'bad' programs in the required time with C tha
n
|> it is to a write the same program 'badly' in Ada.  

Or could the developers just be lazy?  Maybe the next time a bridge is build ne
ar
your home the Civil Engineers will decide it is easer (cheaper) not to do any
load analyze and just build the bridge.  Of course, when the bridge collapses
(just an annoying bug) nobody will complain, right? 

|> There is a program I now
|> use on my PC, GeoWorks, that is a simple, decently implemented of what
|> Windows should be.  The program has received much praise.  From what I know,
|> the program is written mostly in assembler, with some C.  I doubt highly,
|> given the time, budget, and memory constraints, that this program could have
|> been written in Ada, and if the source code was evaluated by the proposed
|> academic criteria, probably would not receive a good grade. Yet the product,
|> albeit with annoying bugs, is a good product.

You don't say what version (1.2 is the latest) but there are still bugs that ha
ve
not been fixed from version 1.0.  Maybe the use of assembler is the problem? 

GeoWorks is mostly written in assembler, but they have been working on versions
of GeoWorks for about 8 years.  The C-64 was the first system to use GeoWorks i
n
83 or 84.

Also they still don't have a SDK, unless you want to buy thier entire Sun
development system.


|>      The question should be how much of the real world show students be
|> taught about?  It is beneficial to teach them to program in a way that is
|> possible only at the few companies in the real world lucky or smart enough
|> to have great software development environments?

No, they should be taught how to do software right and I don't claim that I kno
w
how to do software right or that Ada is the right way.  But it is better than
using assembler or C. (IMHO)

For some reason liability laywers have let software companies get away with
murder.  (If the software dies its your fault not ours).  At some point the
laywers are going to start suing software compaines for liability of their
software the same way that Doctors, manufacturers and other groups are held
liable for their products.  

|> 
|> Greg Aharonian
|> Source Translation & Optimization

						Later,
						Bill Yow
						(713) 283-4051
						yow@sweetpea.jsc.nasa.gov
						byow@mcimail.com

My opinions are my own!			

Re: Software Engineering Education

[David A. Hasan]

In article <SRCTRAN.91Nov16120253@world.std.com> srctran@world.std.com (Gregory
 Aharonian) writes:
>
>     The various suggestions for how to grade software products, while nice,
>don't reflect that in the real world of deadlines and tight budgets, one
>rarely has the luxury (or the ability to plead for cost over-runs) to do
>software nicely in the software engineering sense.

In the context of software engineering EDUCATION, this
argument seems to be equivalent to the following statement:

  "In the real world, nobody has the time to craft
   elegant papers or documents.  Memos and quick notes
   must be thrown together in order to meet real
   deadlines.  Therefore, it is not useful for students
   to spend time in school learning how to write well 
   if the emphasis is on "well" and not on "fast"."

Of course, the reason that it is useful for students to learn
how to write elegantly and program literately is so that when
it comes to meeting deadlines in the real world, they have
some underlying writing skills which will result in a
moderately well-crafted product EVEN IF it is thrown together
quickly.

I would argue (admittedly as an anti-C bigot) that the use
of C in academia works counter to the objective of turning out
students who appreciate the need to coherent, literate
software design.  (Unless, of course, one of the
aforementioned grading schemes is used in conjunction with the
language!)         

(Don asbestos suit...)

-- 
 |   David A. Hasan
 |   hasan@emx.utexas.edu 

Re: Software Engineering Education

[agate!spool.mu.edu!tulane!uno.edu!JNCS]

In article <20600125@inmet>, ryer@inmet.camb.inmet.com writes:
>    25% - Quality (correctness) of the executable program
>    25% - Quality of the written design document
>    25% - Quality of the written test plan and procedures
>    25% - Quality of the user documentation
>
>I thought this was the most intelligent approach I'd ever heard.  Do any
>of you educators have a better idea?  Is this done in other universities?
>
>Mike Ryer
>Intermetrics

When I teach software development courses of any level I break the grade on
the following aspects :
	i. Documentation
        2. Format of code
        3. Design of algorithm
        4. Implementation
        5. Completeness of implementation
        6. Correctness
        7. Output

Their weight is based on level of course and complexity of problem at hand.
This grading supports development of code that can be read and maintained,
vs code that works and produces a correct answer. Usually, correctness and
output do not exceed on more than 2o-25%. Thus there may be program which
are acceptable but may not produce correct output; acceptability is determined
by the other factors. 
I feel I must mentioned that Implementation considers the proper (not just
correct) use of control structures, and abstraction tools as provided by
Ada. (Example, use of For when it should be a While, procedures where functions
,
use of constants, type definitions, etc...)

Jaime Nino
Computer Science Department
University of New Orleans
New Orleans, La 70148

Re: Software Engineering Education

[Ray Harwood]

> [stuff deleted]  [T]he student team can get a max of
> 15 points from correctly working (8 points) and correct styles etc (7 points)
.
> Now this is out of a possible 100 points for the project which is 50% of the
> grade for the class.  The rest of the 100 points for the project are awarded
> for thinking through, defining, and implementing the strategy (process) for
> the project.

At the risk of a little bandwidth, I have attached a text-copy of the program
grading sheet I use in my CS2-based course.  It addresses many issues:  the
program must be documented;  adequate tests must be run to prove "correctness";
proper style must be followed, both in layout and construct; and it must look
profession.  Students are STRINGLY encouraged to turn in assignments in a
pocket-folder, documentation on the left, source and test output on the right. 
Those that just wrap a rubber band around a bundle of "stuff" learn the value
of "professionalism" very quickly!

I developed this form primarily because I felt I was not giving out POSITIVE
feedback, simply marking Bad Things.  Now, there is a block for my comments in
each category, and I don't leave any block blank -- even if I just scribble
"Good!" or "OK".

> To be honest, the students have a very hard time with this.  They can easily
> see the solution to the project.  In fact, some of the student could sit
> down in one day and complete the project and have it work (these again are
> two week courses).  Having them describe the approach and manage it is much,
> much more difficult.

Some students will NEVER get the hang of it.  Many readers of this digest are
most likely four-year college PhDs with pick-of-the-litter students...  I'm
"just" a two-bit associate faculty member at a community college.  Yes, we do
have quite a few top-notch students, but we also attract those that can't "cut
it" at the U.  It makes my 2 cents worth it when "the light comes on" for one
of THESE students.  (My apologies to our foreign readers for my use of idioms!)
 
Unfortunately, we as instructors are not given good training in how to
*gracefully* tell a student, "You don't seem to have an aptitude for this!"

> [...]    My students would have a much
> easier time if the end goal were well engineered systems versus getting it
> to work and moving on the the next task.

Well, I'm not sure the students would have an EASIER time, but they sure would
LEARN a lot more! <grin>

Ray
-----
Ray Harwood           |Data Basix           |Associate Faculty, East Campus,
Voice: (602)721-1988  |PO Box 18324         |   Pima Community College
FAX:   (602)721-7240  |Tucson, AZ 85731     |Instructor in Ada and Pascal
CompuServe: 76645,1370|AppleLink: DATA.BASIX|Internet: rharwood@east.pima.edu
=========================  Cut Here  ===================================
                             Program Grading Sheet                             
+-------------------------------------------------------+---------------------+
| Programmer Name:                                      |Date Due:            |
+-------------------------------+-----------------------+---------------------+
| Program Number:               | Option:  A  B  C      |Date In:             |
+-------------------------------+-----------------------+------+--------------+
|       Grading Item Description:    [] Items                  |  % of Points |
|                Comments                                      | Max  | Earned|
+--------------------------------------------------------------+------+-------+
|Accompanying Narrative & Documentation:  [] Test Design       |  12  |       |
| [] Structure Chart  [] Program Listing  [] Test Input        |      |       |
| [] ^ w/Data Flows   [] Algorithm Descr. [] Test Output       |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Indentation & Layout: [] Var/Const/Proc/Func indented         |  16  |       |
| [] Program/Begin/End align    [] Procedure/Begin/End align   |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Comments:    [] Program purpose     [] Proc/Func purpose      |  16  |       |
| [] Var/Const declarations    [] Section header   [] In-line  |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Naming Conventions:  [] Procedures (verb/subject)             |   8  |       |
|    Useful, descriptive: [] Vars  [] Const  [] Func           |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Proper Langauge Constructs:  [] Simple "main" routine         |  12  |       |
| [] Passed parameters    [] Limited "global" vars             |      |       |
| [] Proper var types     [] Structures model real data        |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Illustration of Technique & Objective:                        |  10  |       |
| [] Required outputs  [] Required computations                |      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Proper Operation: [] Complete test output  [] Full test suite |  10  |       |
| [] Computations correct  [] Outputs correct  [] Labels/format|      |       |
|                                                              |      |       |
|                                                              |      |       |
+--------------------------------------------------------------+------+-------+
|Ease of Understanding: [] Neatness  [] Organization           |  16  |       |
| [] Readability  [] Completeness  [] Professional appearance  |      |       |
|                                                              |      |       |
|                                                              |      |       |
|                                                              |      |       |
+----------------------+--------+------------------------------+------+-------+
|  Late Penalties      |Classes | Percent of Total Points..... | 100  |       |
|  1 class   -  2%     |Late    |                              +------+-------+
|  2 classes -  5%     |        | Total Points Possible.............  |x      |
|  3 classes - 10%     +--------+                                     +-------+
|  4 classes - 16%     |Penalty | Total Score.......................  |       |
|  More - 5% per class |        |                                     +-------+
+----------------------+--------+                                              

Re: Software Engineering Education

[sun-barr!cronkite.Central.Sun.COM!newstop!sunaus!assip.csasyd!condor!dave]

In <1991Nov15.191846.11278@milton.u.washington.edu> mfeldman@milton.u.washingto
n.edu (Michael Feldman) writes:

> Editorial comment: The notion that, collectively, we don't teach the
> right stuff is a canard, in my experience. Just because the students don't
> learn it (or carry it with them to industry) doesn't mean we don't teach
> it.

Sorry Mike, I can't agree with you on this - from my perspective down here, at 
least.  We take a goodly share of computing science graduates, frequently with 
extremely good results.  My perceptions of the failure of the Universities to 
teach "real-world" computing is based on my work alongside these people.  I'm 
certainly not saying that all Universities are the same, or that they don't car
e 
about "real-world" computing at all - I just don't see Universities getting it 
right yet.

I don't understand your "Just because the students don't learn it (or carry it 
with them to industry) doesn't mean we don't teach it."  It isn't "teaching" if
the students (at average grade and above, anyway) don't learn and retain it.

> We have observed that, in industry, when a project is under the gun,
> all the platitudes about good style, test plan, documentation, etc., get
> swamped by the demand to get the sucker running. Gerry Weinberg, in his
> classic "The Psychology of Computer Programming", pointed this out 20
> years ago. Maybe it's not true in your company, of course not...

Of course not!  :-)  Cruel blow that one, Mike.

Dave
-- 
David Smart, Computer Sciences of Australia.
Net: daves@assip.csasyd.oz.au

Re: Software Engineering Education

[timothy shimeall]

Has anyone considered the difficulty in even defining what "real world
computing" is, let alone teaching it? How would you provide a willing
university with the information it needs to design a "real world
computing" curriculum?

+ "Real world computing is what my company does" - This works great,
  until your graduates start working for more than one company...

+ "Real world computing is what programmers in general do" - I welcome
  suggestions as to how:
   a) A survey can be conducted to determine what programmers in
      general do (and how the results can be checked to determine
      that the programmers filled them out, not management or 
      clerks);
   b) A source of funding can be identified to pay for the survey
      mentioned in a)
   Note that the net, big as it is, is a biased sample.  People with
   time to spend on netnews aren't likely to be typical programmers.

   Note also that a casual survey of newspaper want ads shows that
   the most-requested types of programmers work in COBOL and RPG
   (Using ads from the San Jose Mercury News, serving most of Silicon
    Valley).  This may suggest that "programmers in general" isn't
   even the correct target, definitional problems aside.

+ "Real world computing is what the top-of-the-line companies do"
   -- this breaks down into two methodological problems: 
   a) How do we identify "Top-of-the-line" companies
   b) How do we get said companies to allow us to identify what
      their programmers do

As one final note, consider a MUCH simpler problem - profiling
CS professors (this is simpler, as the professors wouldn't have to get
an OK from corporate lawyers to describe their working habits).  While 
I've seen figures for average time/week for professors at various levels,
I've never seen figure breaking down what professors do during that time...
-- 
Tim Shimeall ((408) 646-2509)
The proper response to detecting a bug isn't to fix the bug - it's to make 
sure you'll never have to worry about that bug again.  --- Richard Hamming