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 not 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 Good Day to Die. Ron considers the problem of late software delivery in industry and wonders,
What if the rule was this?

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.

Does that sound familiar? His answer sounds familiar, too. If you program in the way that the so-called agile methods people suggest, this won't be a problem. 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. -----