CS 2800 Lab Instructions for Students

We are running labs in the form of interactive sessions, during which are you asked to defend your code or proofs to fellow students, or to critique the work of other students. This is a situation very common in industry, where large-scale software development is naturally done in teams, sometimes of dozens or even hundreds of people. To ensure integration of the various components, you might have to defend an idea, defend a solution, or illustrate a problem you have encountered, to colleagues, managers, clients, or business partners. Or you might find yourself in the role of the colleague or (later) manager to whom such work is defended. In addition to practicing these situations, you will also sharpen your presentation and analytical skills.

In our labs, each pair (or triple) of students who have worked together on the homework due earlier the same week act either as a "defending team" or as a "questioning team", roughly in alternation. A defending team and a questioning team will be determined to form a "quadruple" (this will change each week). The TA for your lab will inform you approximately on Wednesday whether your pair will defend or question. If you are chosen to question, you will also be given access to the code the defending team submitted for the homework due earlier that week.

Preparation for Labs

Defenders: Go over the solutions you submitted for the homework. DO NOT change or fix them in any way, as you will be asked to defend exactly what you submitted. Make sure you can justify the way you solved a particular problem, especially if there are several solutions.

Questioners: Study the solutions of the defending team. Run it in ACL2s, and try out some of their code. Pick a few of the more interesting functions, and ask yourself the following questions:

• Is the code of the defending team correct? If not, can you find a "counterexample", i.e., an example where the function returns the wrong result, does not terminate, or causes a contract violation? This is always the most important question to ask.
• Is the code elegant, readable, and understandable? Is it efficient? Can you make it more efficient by sacrificing compactness? Can you make it more compact while forgoing efficiency?

Now think about questions to ask of the defending team:

• If you think their code is incorrect, challenge it by pointing out the part that you think is buggy, or by suggesting the counterexample you found. You do not have to do the thinking for them: if you think something might be wrong, let them explain it to you.
• If you think their code is correct, ask why they made certain design decision. Don't ask: "Is there another way to write your code?" The answer is always Yes! Offer a particular alternative implementation (e.g., your own solution from the homework), and ask them to compare the two solutions. Criteria are correctness, elegance, readability, and efficiency, roughly in that order.

As a simple example, consider the iff function from homework 2. Suppose the defending team offer this as the body:

(or (and a b) (and (not a) (not b)))

You might tell the defending team: "The English description of iff says: '(iff a b) is t if a and b are the same.' Isn't there a more direct way to test sameness?"

You don't necessarily have to suggest an alternative solution that you are absolutely sure works --- it is the defending team's job to convince you that it does or it does not. Again, no need to do the thinking for them (you will be the defending next time!). Just acknowledge if your suggestion doesn't work.

Important: no technical question is unfair. If you ask a very hard question that is beyond the class material, the defending team will not be punished for not being able to answer. But you will be rewarded for coming up with a good question, if it is germane. We love outside-the-box thinking.

The Lab

Each quadruple will be given a time slot. The solution of the defending team will be displayed. The questioners then ask their questions from most interesting to least interesting.

Experience Points

You can earn up to 20 EXP for your role as defender or questioner. These points are awarded by the TA. In addition, 10 EXP is awarded to the best defending team, 10 EXP to the best questioning team, and 10 EXP to the best quadruple. These bonus points are awarded based on a vote by all participants in the lab. That means that you can get up to 40 EXP per lab. Note that anything above 20 EXP constitutes bonus points.

Suggestions For Making the Most of Your Time

Defenders: Be concrete and brief. We want to have as much time for the actual discussion as possible. You don't have to explain anything obvious.

If you think a particular suggestion from the questioners will lead nowhere, demonstrate this to them. If you think a particular suggestion is equivalent to what you did, or will make hardly any difference, say so. The point is not to "please" the questioners. It is to answer their questions to the satisfaction of your peers. If you cannot answer a question immediately, try to figure it out in real time: use the board, talk with your partner, etc. The TA will intervene if the question is too hard; you will not be penalized in such cases.

Questioners: Make sure you are convinced by whatever answer the defenders provide. If not, keep insisting. Suppose that a lot of your money depends on the correctness of their code. Also, since there won't be much time, make sure you pick your questions wisely, following the MIF principle: most interesting first. Don't ask trivial or obvious questions. Time is limited and you will be graded on how well you use it. Prioritize.

If the defending team seems puzzled by your question, and you think you know the answer, help them. If a question you were planning to ask was already adequately addressed by another quadruple, acknowledge that and move on to your next question. This shows you are well-prepared, flexible, and have paid attention.

Both: Speak loudly and clearly. Be polite, respectful, and professional.

All: Pay attention and participate in the discussion. If you play games on the console or read email, you jeopardize your own experience points for this lab EVEN if it is currently not your turn. You have to vote at the end of the lab and that only makes sense if you're paying attention. Watching a code review is also an educational experience.