COS 333 Project: The Week After Break

Sat Mar 24 13:52:02 EDT 2012

Demo days begin May 9, which is barely six weeks from now, so it's time to get real serious about projects.

By the end of this week

  • Resolve any open issues in your design document or that you have thought of since: what the components are and what they do; what the interfaces are between them; how they exchange what kind of information. You might find it useful to step through scenarios and common use cases, thinking carefully about what has to happen; that will help resolve who does what with what data. Another way to look at it: express goals as "The user will be able to ...", where the "..." is a specific feature or operation.
  • Make sure the short term risks are resolved: access to information (registrar, maps, code, ...); access to systems (databases, server space, CGI or whatever, ...); access to enough data that you can give your system a reasonable workout.
  • The basic plumbing should be working, and any systems you need should be installed, running, and accessible to all group members.
  • Think about database structure and access. The access functions for your application should not be too dependent on the specific tables; that way, you can change your mind about organization without too much fuss.
  • Think about getting users early. If you get feedback soon, you can react to it. There will be some class discussion about how to get the most out of your early users.
  • Put your code and documents under SVN, GitHub, or other management system. Maintain your timeline file. Look back at the milestones in your design document. How well did you meet the first ones?
  • Hold your first meeting with your TA. Everyone must attend these meetings; they are a graded component of the course.

    Weekly project meetings

    From now until the end of classes, you must meet once each week with your TA for about half an hour. This requirement encourages you to think about what you have done and what you're going to do next. It's a chance to talk things through, and get advice and opinion from someone supportive who is looking over your shoulder. The TA's job is not to solve your technical problems, and it's certainly not to tell you what to do -- it's your project. But pay attention, especially if your TA is concerned about something.

    Everyone must come to all meetings if at all possible. If you absolutely must be away, courtesy and a concern for your grade mandates sending an explanation well before the meeting. Unannounced absences, and especially total no-shows, are unacceptable.

    Be prepared. You might find it a good idea to meet among yourselves the day before your TA meeting. The time you spend thinking about and organizing for your meeting will pay off. The TA's are looking for you to be obviously prepared, with an organized agenda, and volunteering information; they should not have to drag things out of you, and they will definitely be unhappy if you're clearly just winging it with no evidence of effort ahead of time.

    Everyone participates, is engaged, contributes. It should not be one or two people doing all the talking while others sit passively or fall asleep.

    Given the short time scale, there really has to be progress every week. The TA's will be looking for evidence that you're getting somewhere, though of course there will be setbacks and dead ends; we just want to make sure those are under control.

    We're also looking for evidence of planning, that you have a clear idea of what the next steps are each time. Fuzzy ideas or more of the same ("We're still working on getting the bugs out") are not a good sign.

    Of course in return, you have every right to expect that the TA's will meet you at the scheduled time, will also be well prepared, will have been thinking about your project, and will do their best to advise you well.