The good news for the students is that by this point in the lecture we've already talked about at least some of the hardest work that they haven't thought about at all up until this point: deploying their code to the client production system. It's especially difficult because there may be parts of it that are completely beyond their control. Coordinating with client personnel that aren't normally involved in the project, working through whatever release activities are necessary for the client to get code promoted to production, adding IP addresses to whitelists in firewalls, and the like are just some of the things that will be done primarily by people other than the student teams, and as such those activities might be hard or time-consuming from the calendar perspective.
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. :)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.