Course Project

Collectively, the project accounts for 45% of the course grade. That would suggest to me that one should read this page closely.

Overview

The intent of the course project is to provide deep, hands-on experience with a storage topic interesting to each student. The class will separate into groups of two, with the occasional group of three being permitted on a per-case basis (such groups would naturally be subject to an increase in instructor expectations). The timing and grading weights for the different parts of the projects are given on the course page.

In general, groups will base their project on the three "Program" assignments that take place in the first half of the course. However, where you go from this base is up to you. Your project must take the basic concept of a filesystem and add functionality that addresses one (or more) of the following questions:

• How can I improve the availability and/or recoverability of this storage?
• How can I make this storage network-accessible effiently?
• How can I improve storage efficiency?
• How can I improve performance?
• How can I improve security?

To get ideas for projects, some lecture time will be devoted to an "overture" summary of topics that will be covered later in the course.

Groups will submit an initial proposal that describes their project and how it will be achieved, including a detailed weekly schedule. Groups will also, at this time, schedule time with the instructor to discuss the proposals.

Groups may need to alter their project plan (or even abandon it for something else) based on feedback at this stage. A finalized proposal will be submitted after this revision process.

Work will then proceed in depth on the project. Students must aim to have measurable units of work ready each week, as consistent effort over time is the key to success -- to help students achieve this, you'll be submitting a very brief weekly status report.

During the project, there will be two project work days that take place in class. The instructor will meet with groups individually to offer feedback and advice. Attending work days is mandatory — this is how I track individual student contribution and project health!

Finally, when the project is complete, there will be three forms of deliverable:

• First, all project materials as well as a written report will be turned in.
• Second, groups will present a final presentation to the rest of the class on their project.
• Third, groups will schedule an out-of-class final demo to the instructor, which will allow greater depth of discussion.

Each stage of the project will be governed by a "business scenario" -- a situation in a corporate environment that would lead to the deliverable being asked for.

Note: At any stage, the instructor may opt to require resubmission or a change of plan. This is independent of the grade for that stage, as the cause could be quality (submission was incoherent) or content (submission was coherent but the design expressed was infeasible).

The precise requirements for each of the deliverables are described below.

Initial proposal

Business scenario: You're an individual contributor on a technical team at a storage company. You have an idea you'd like to pursue outside your normal job responsibilities, and are pitching to your manager for approval and perhaps even budget.

The proposal consists of:

1. A brief write-up (3-4 pages) that describes the project.
2. A 60-minute meeting with the instructor to present and discuss the proposal. In the meeting, a 5-10 minute presentation is expected, followed by discussion. NOTE: See "How to schedule meetings" below.

The proposal should answer the following questions:

• What will be built? What is the high-level architecture? The most basic design questions should have been answered by this point (e.g. language, platform, algorithm, etc.).
• What will be the criteria for success? Be specific. Include a high-level description of your test plan, including what kinds of testing is needed (unit, integration, performance, etc.)
• What are the major risks and unknowns involved?
• Do you need extra hardware resources? (Reasonable hardware requests can be granted for projects)
• What is the exact timeline for the project?
  • On a per-week basis, indicate what tasks will be done by what person.
    NOTE: This timeline is what will be reflected in your weekly status reports (described below!)
  • Be sure to identify the new skills will need to be developed to complete the project, and include the time to learn these skills in the timeline.
  • If your team server is being used, consider how its use may conflict with course lab assignments -- note this in your timeline.

Grading for this deliverable will be based on:

• Completeness of proposal versus the questions above.
• Clarity of write-up.
• Professionalism of presentation.

Independent of the above, receiving feedback that alters the project will not bear a grade penalty. It is expected for students to new to the subject matter, and to potentially need significant guidance in honing their projects at this stage.

Tip: Structure your written proposal for rapid readability: brevity, diagrams, bullets, and tables are preferred over long paragraphs!

Final proposal

Business scenario: Your team is receiving more work from senior management, and your proposed project is at risk of being cut. Your manager would like to defend it to senior leaders, so it is important that the plan is complete and defensible at this time.

Based on feedback received, you will update your proposal. The structure is the same, but the bar for quality and completeness is raised. Grading for this deliverable will be based on the attributes from the initial proposal as well as:

• Successful incorporation of initial proposal feedback.
• Feasibility of the presented plan.
• Correct use of the concepts covered thus far in lecture.

It is possible that you may receive further feedback at this stage.

Weekly status reports

Business scenario: What once was a small organic project within your team has gained major visibility in the company. Marketing is advertising it on customer-facing roadmaps and sales is talking it up to customers. To satisfy upper management, your manager has requested status reports that will be included in higher-level meetings.

The tribal language of the modern corporation is Microsoft PowerPoint, for better or worse. You'll be summarizing your weekly status as a single powerpoint slide based on this template.

Update 10/15/2019: I've simplified the report format and made it more flexible; see powerpoint for details, but we basically need to see how your timeline is standing up to reality. A suggested format is given, but you may use another format as long as it captures (1) completed tasks, (2) confidence in upcoming tasks, and (3) changes being made to the timeline.

The most important thing is to show how your timeline tasks are getting done. If things are progressing differently than you expected, don't hide that! Just report honestly what's going on. If things are looking back, contact the instructor proactively to propose a revised timeline.

Having honest difficulty with new subject matter is not grounds for a bad grade. However, misrepresenting progress will be penalized, as will failing to take proactive steps to correct or revise a schedule that is slipping constantly.

Tip: These reports are for your benefit -- past students asked for more structure to avoid a big rush at the end. Don't fight the structure, use it to remove risk and stress from the project.

Workdays

Business scenario: An experienced senior developer has offered to drop in to assist with project planning. A lot of good can be had from an informal conversation -- don't waste the opportunity.

I want you to be successful in this project, so twice during the semester, we'll suspend lecture and use the time as an open work day. This serves two purposes: it gives you time to work and it lets me speak with groups one-on-one to offer help and assess their status. You can also use this time to collaborate with other groups if you wish.

NOTE: Workdays are not optional!

You should come prepared to discuss and demonstrate your progress so far as well as ask any questions you can to help things run smoothly. Also, I will want to see that you've done the things that you've said you've done in your weekly reports to date.

There's no explicit grade associated with workdays, but I may ask you to steer your project in a different direction if things aren't working well.

Tip: This is another course feature added for your benefit -- the idea is to give you feedback before a grade is on the line.

Final report

Business scenario: A project isn't complete until it's documented. Explain your work in detail for future colleagues to build upon.

This report will, in a maximum of 8 pages, describe the results of your efforts. Below is a reasonable outline for this document.

• Introduction: What is the problem or market you're addressing?
• Design: What is your approach to the problem? Discuss your design in depth. Diagrams are likely useful here.
• Implementation: Describe your implementation fully, making sure to start at the beginning (language, platform, etc.).
• Evaluation: Conduct a study to evaluate how well your system fulfills its goals. Also include a performance study featuring appropriate benchmarks. Be sure to discuss WHY the numbers are the way they are. If you get disappointing results, discuss those too (don't hide them!).
• Conclusion: Summarize the key benefits and tradeoffs of your system. Describe potential avenues for further improvement if you were to continue on the project.

Grading for this deliverable will be based on:

• Completeness versus the above.
• Clarity.
• Correctness.

Note: actual health and quality of the project will be assessed in the demo to the instructor (see below).

Tip: Less is more -- look for ways to shorten this document while still covering everything you need to.

Final presentation

Business scenario: You've completed your project, and in the time you've been working, visibility of your once-small project has ballooned into a departmental priority. Product managers and executives are suddenly claiming indirect credit for the work, and you've been asked by the senior director from earlier to present your work to the departmental senior staff meeting chaired by the executive vice president of engineering. Don't screw up.

The final presentation consists of a 15-minute presentation to the rest of the class (plus time for Q&A). The presentation should answer the following questions:

• What is the problem or market you're addressing? (in the scenario, you're presenting to a broader audience, so start at the beginning).
• What is your approach to the problem? What is you design?
• Describe the implementation process. Have any major changes been incorporated since the proposal was finalized? How did the project proceed compared to the timeline presented in the proposal? Explain any differences.
• What were the most challenging problems encountered? How were they solved? What limitations still exist in the project?
• Evalute your project in terms of its core goals as well as its IO performance.
• DEMO: SHOW US WHAT YOU GOT.

This overlaps the report described above somewhat, but whereas the report discusses the final product, this presentation is focused more on the implementation process.

As before, you likely want to cover the first bullets quickly so as to maximize time for the good stuff, your demo.

Grading for this deliverable will be based on:

• Completeness of the presentation versus the questions above.
• Professionalism of presentation.
• Smoothly staying within the time limit.
• Correct use of the concepts covered in lecture.
• Successful incorporation of feedback throughout the project.

Note: actual health and quality of the project will be assessed in the demo to the instructor (see below).

Tip: We're looking for a high degree of polish on this talk. Use this chance to impress!

Final demo

Business scenario: With your project complete, the technical director of your group has asked you for a technical deep dive. Unlike the presentations thus far, the technical director is concerned with a getting deep understanding of your work in order to assess its merit as the basis for a major product or initiative at the company. Expect detailed discussion and difficult questions.

The final demo consists of a 60-minute meeting with the instructor (10 minutes for talk+demo, then interactive Q&A). NOTE: See "How to schedule meetings" below. In this meeting, your project will be put through its paces, code will be inspected, trade-offs will be debated, etc. It can basically be thought of as a defense of your work against scrutiny.

Your demo will occur after your final presentation to the class.

Grading for this deliverable will be based on:

• Completion of objectives laid out in proposal and outline.
• Technical merit.

Tip: Do a really good project.

---

How to schedule meetings

The project involve scheduling out-of-class meetings. To give you some real-world experience, we're going to do this corporate-style, because you don't send around doodle polls in industry. Instead, we'll use Microsoft Outlook. I keep my Duke Outlook calendar up to date, and you'll use Outlook to identify a free spot between 10am and 4pm that works for your group. Send me a 1-hour meeting invite in such a timeslot that includes your team members and myself; the location will be my office, Hudson 106. I will accept it (thus confirming the meeting) or decline (likely starting a conversation about alternate times).

NOTE: You're required to have your meeting confirmed by the deadline listed in the course page, not just requested. This means that being on time (and hence getting a good grade) depends on something outside your control: myself and the time I take to respond to your request. This is a realistic situation in the working world, and the way you address it is by being proactive! I'll do my best to respond in a timely manner, but I'm not responsible for projects deemed late due to attempts to schedule on short notice!