A few words about the Labs
A key learning component of this course is to build a highly available, scalable, fault tolerant, and transactional key-value store. Key-value stores are widely used in cloud computing. The project is written in Java, derived from a similar one designed for the MIT graduate distributed systems course. A hallmark of our project infrastructure (developed at UW Seattle, incidentally, with a CS5414 graduate as one of its main architects) is extensive support for thorough testing and debugging. Each lab has a model-checking-based test suite that you can use to validate your implementation.Lab 0 and Lab 1 of the project are to be done individually. (Note that Lab 0 does not have a turnin.) The other labs (2-4) are to be done with a partner. After the introductory labs (lab 0 and lab 1), each of the other labs is due every two or three weeks.
The labs are autograded by a model checker, and that means you will need to come up with solutions that work in all cases. Except for the writeup, the labs are (for the most part) self-grading - we give you all of the test cases we run.
The best way to write code that works in all cases do this is to carefully think your design before writing any code. Design before code is especially important for distributed systems where the number of possible code paths is exponential in the number of messages, the cost of uncaught errors in production code is enormous, and it is often infeasible to catch every possible error through testing.
This is very different from other CS classes you may have taken. If you think we are just saying that and we don't really mean it, please understand that it may take you as much as ten times as long to complete the assignments if you start writing code before you carefully think through the design with your partner. Debugging typos can be laborious but is a reality we all face. Debugging distributed system design errors by testing is extremely time consuming.
To encourage you to fist design then code, we ask for a design document for each lab, worth a sizeable portion of the total value of the lab, due a week in advance of the lab due date (except for lab 1) and then optionally revised and resubmitted with the lab. You and your partner should agree on the design document before writing any code. Of course, you may find from time to time that you need to update the design, but you want to try to minimize that.
Finally, we also ask you to provide a short post-mortem with each lab: what worked for you, and what didn't.
We strongly recommend you get an early start on the labs. Many students underestimate the difficulty of the assignments, and leave themselves too little time to finish in time. The most common comment about the labs is that students wished they had gotten an earlier start.