Speaking of calendars, I like to back into a few dates to instill a sense of urgency in the students at this point.
(Note that the lecture was given on March 2nd.)
The calendar begins without the highlighted dates. The first question is: Who knows when everything is due? Typically only one student out of both sessions will know the due date (May 14th, for this year's students). The second question is: Who knows when you should be principally finished with all the work? When is the code complete date? No one ever remembers this date (April 22nd). A more interesting question is why is that the code complete date? It's mainly because the intervening weeks are full of meeting other graduating student obligations, so the instructors want to make sure the students have done most of the work before the nuttiness ensues.
Both of these dates, by the way, are in the syllabus. The instructors have gone so far as to make the entire schedule into a Google calendar so that the students can easily import the dates.
The final date (or first, chronologically), is a suggestion I make for the students. If there's still hard work to be done after that date, the project is in jeopardy. The scary thing about that date is that it's roughly a month after the date of the lecture. At this point, most of the students haven't actually started working on the project itself yet. I urge them to go ahead and start making a backlog of things that they know will have to be done (either because we've talked about it or because it's in the syllabus). From that list, make a guess at what the hardest or riskiest things are and push those to the top. Go over the list with the instructors to vet it with them.
What's a backlog, you ask? That's a good question... one we'll cover in the next post. :)