TITLE: Can You Turn It In Now?
AUTHOR: Eugene Wallingford
DATE: September 03, 2004  4:45 PM
DESC: When you're an XP project, today is a good day to die.
-----
BODY:
Conventional wisdom is that many software projects are completed late
and over budget.  I don't know whether this is true, or to what extent,
but few dispute the claim.  Within the software engineering community,
this assertion is used as motivation to develop more rigorous methods
for building software and managing the process.  In the popular press,
it is viewed with much head shaking and a bit of disdain.  Yet people
must continue to buy software.

We face a similar issue in academia.  Many professors accept late work
for a few days after an assignment is due.  Sometimes they assess a
penalty, such as 10% of the available points per day.  But compassion
usually dictates some degree of flexibility with our young charges.

My grading policy has always been <B>not</B> to accept late work.
I tell students to submit their best available work at the time the
assignment is due.  I also place a lower bound on the acceptable
quality of a submission:  If a program doesn't compile, or compiles
but blows up horribly when run, then the resulting grade will be
quite low.  I tell students that, all other things being equal, a
compilable, runnable, yet incomplete program is more valuable than
a program that doesn't compile or run.  It's hard for me to have much
confidence in what a student knows or has created when even the
compiler balks.

I'm reasonable enough to make exceptions when events warrant them.
Sometimes, extenuating circumstances interfere with a student's
opportunity to do the assigned work in a timely fashion.  Sometimes
a reasonably good, nearly complete program causes an exception in an
unusual situation that the student doesn't yet understand.  But for
the most part, the policy stands.  Students long ago stopped questioning
this rule of mine, perhaps accepting it as one of my personal quirks.
But when deadlines approach, someone will usually ask for a break
because with just a little more time...

Of course, I also encourage students to do short iterations and
generate many "small releases" as they write programs.  If they
work systematically, then they can always be in the position of
having a compilable, runnable -- if incomplete -- program to submit
at every point in a project.  I demonstrate this behavior in class,
both in project retrospectives and in my own work at the computer.
I don't know how many actually program this way themselves.

These thoughts came to mind earlier this week when I saw a message
from Ron Jeffries to the XP mailing list, which appeared in expanded
form in his blog as
<A HREF="http://www.xprogramming.com/Blog/Page.aspx?display=GoodDayToDie">
   Good Day to Die</A>.
Ron considers the problem of late software delivery in industry and
wonders,

<BLOCKQUOTE>
What if the rule was this? 

<P> <I>On the day and dollar specified in the plan, the project will
terminate.  Whatever it has most recently shipped, if it has shipped
anything, will be assessed to decide whether the project was successful
or not.</I>
</BLOCKQUOTE>

Does that sound familiar?  His answer sounds familiar, too.  If you
program in the way that the so-called agile methods people suggest,
<I>this won't be a problem</I>.  You will always have a working
deliverable to ship.  And, because you will have worked with your
client to choose which requirements to implement first, the system
you ship should be the best you could offer the client on that day.
That is fair value for the time spent on the project.

Maybe my grading policy can help students learn to produce software
that achieves this much, whatever its lifespan turns out to be.
-----