Re: Marking of assignment 2

Ed Casas (edc@ece.ubc.ca) Thu, 24 Feb 2000 09:06:38 -0800 

Date: Thu, 24 Feb 2000 09:06:38 -0800
From: Ed Casas <edc@ece.ubc.ca>
Subject: Re: Marking of assignment 2



On Wed, Feb 23, 2000 at 10:04:40PM -0800, ddowler wrote:

> If the actual solution of the problem is too easy to forge, then why
> don't we email our .com files and the TA can test them for himself?  If
> you tell us what the name of the .com file should be (i.e. asgxyyyy.com
> where asgx is the assignment number, and yyyy are the last 4 digits of
> our student number), then the TA can put them all in the valarrow
> directory, and test the whole class in a few minutes.  Is this
> unreasonable?

Actually, yes.

In previous versions of the course I have asked students to hand
in floppies with the source and executable versions of their code
and then had the TA run and test each solution.

These schemes have proven to be less efficient (in terms of TA
time) than marking paper printouts.  I was shocked at the number
of people who misunderstood the submission procedure or who
thought the TA would ``figure it out'' (unreadable files, files
in the wrong format (DOS vs UNIX), viruses, people who insisted
on using Borland Turbo Assembler syntax instead of the free
assembler, people submitting the wrong files (source instead of
executable or vice versa...).  It turned out that high-tech
methods of submitting and marking assignments involved too much
overhead to be worthwhile for a course like this (an on-site
course with a relatively small number of students).

I've also had students electronically submit source code via a
"trap door" set-uid unix program (the details are on previous
year's web pages if you're interested in the details).  This
introduces another whole set of problems related to
authentication, security, and system availability.  And it
doesn't help with the above problems.

The whole experience convinced me that we still have a long way
to go before electronic "documents" become as easy to use as
paper ones.

By the way, how do you know the last four digits of the student
numbers would be unique?

> Also, why did we have to use the exact 4 functions that you
> suggested?  I used a slightly different algorithm that worked
> fine.

One of the purposes of the assignment was for you to practice
writing and using functions.  Of course, using another set of
functions would work.  But it would take too long and would be
too subjective a decision for the TA to evaluate whether you had
used "enough" functions and made the "right" choice of functions.

In "real life" your client/customer/manager will give you a
specification or a statement of work and you will be expected to
come up with a solution that meets those requirements.  These
requirements will often constrain the solution (e.g.  ask you to
use a specific compiler, library, chipset, ...).

So think of these assignments as practice for the real world.

> Lastly, I think it should be noted that the workload for this
> course has been, by far, the largest of the third year courses,
> so I don't think a little more leniency would be unreasonable.

Programming courses and lab courses do require more time.  The
reason is that these courses require that you build working
hardware and write working programs.  By their nature these tasks
are "all or nothing" in the sense that it's immediately obvious
when your solution is "wrong."

This is in contrast to courses that only require problem
solutions on paper.  In these courses you can "get by" with a
fuzzy understanding of the material and answers that are "partly"
right.

Don't worry!  You *will* be rewarded for all the time you've
spent on the labs and assignments.  70% of your final mark is
determined by your mid-term and final exam marks.  Your "reward"
will be that you will do well in the exams.

I also hope that this course, more than most others, will help
you develop useful and practical problem-solving skills.

> If the comments are going to be marked so in-depth, then
> shouldnt we get an in-depth description (i.e. mark breakdown)
> of what is expected?

I do give you an in-depth description of what is expected.  But,
for reasons explained earlier, I don't tell you exactly how an
assignment will be marked.

> I don't think it would bias our efforts, since nobody worries
> about the comments until a solution is reached anyway (I think
> I speak for everyone when I say that).

Yikes!  Maybe we should talk about good software development
practices.  Only the most trivial programs can be developed over
a short enough time and by so few people that the documentation
can be put aside "until a solution is reached".

By the way, thank you (and Jonathan) for the feedback about the
course.  It may not show in my responses, but I do appreciate it.

-- 
Ed Casas   edc@ece.ubc.ca   http://casas.ece.ubc.ca   +1 604 822-2592