Help Understanding Programming Assignments

There are many different reasons for having students complete programming assignments. As a result, they come in many different formats, require many different things, and can vary considerable across courses. This document will help you understand the differences and why they exist. See the "Policies" page for specific policies about this course.

1 Some Learning Objectives of Programming Assignments

In this course, programming assignments help you analyze (i.e., draw connections), evaluate (i.e., justify a decision), and create (i.e., produce original programs). They also help you assess your progress in these regards. As a practical matter, programming assignments will also help you:

Get better at reading the various different kinds of documents that are used in software development processes (e.g., textual descriptions, needs lists, requirements specifications, detailed design documents, etc...).
Improve your software engineering skills (e.g., introduce you to tools, make you more efficient, improve your planning and scheduling, etc...).

2 The Documents Comprising an Assignment

In some courses, the descriptions of programming assignments are very similar to the descriptions of other assignments. In other words, they have the form of academic documents. In this course, you will read and work with the kinds of documents that are used in the "real world". However, since you are still a student, you will need some information that is not normally provided in the real world. Hence, programming assignments will consist of two kinds of documents. Though it may take you some time to get used to this approach (because it is probably different from anything you have seen in the past), it will help you learn to read and use the kinds of documents used by professionals and make you a better programmer/software engineer.

2.1 The Types of Documents

The main document for each assignment will be written for you as a student and will include such things as an overview, instructions, hints/advice, special submission and grading rules, questions to think about, and links to the other documents. These documents should be clear and not contain errors. So, ask if you are unsure and you will be given a clarification/correction if you're correct and an explanation if you aren't.

The other documents for each assignment will vary. You may be given test plans, detailed design documents, abstract design documents, requirements specifications, needs lists, and/or user stories. In general, these documents will require less of you early in the semester (e.g., just code construction) and more of you later in the semester (e.g., design, construction, and testing). Depending on the course and the learning objectives of the assignment, these professional-style documents may be unclear and/or contain errors, as they do in practice. So, ask if you are unsure, though you may not always get the kind of answer you are hoping for.

Note that specifications are often numbered. This does not mean that the specifications correspond to steps (or an order). Instead, the numbers are used as identifiers (so that the specifications can be referred to). When the numbering system is hierarchical (e.g., 1, 1.1, 1.1.1), the hierarchy indicates additional detail. So, specification 1.1.1 adds detail to specification 1.1 which adds detail to specification 1.

2.2 Using the Documents (i.e., How To Proceed)

The best way to proceed is to start by reading the main document from top to bottom, so that you know what is expected of you as a student.

Then, change roles and start thinking like a programmer and/or software engineer. That is, read the other relevant documents and complete the various tasks.

After you think that you have satisfied everything that is required of you as a software engineer, start thinking like a student again. Re-read the main document and make sure that you have followed all course/assignment policies and satisfies all of the course/assignment requirements.

3 Multi-Part and Single-Part Assignments

Multi-part assignments are usually designed to force/encourage you to use a particular process. When left to their own devices, students in programming/software engineering courses often use processes that are known to be inefficient and/or ineffective. Unfortunately, no matter how frequently or effusively they are told that this is the case, they use those processes anyway. A multi-part assignment is one way for an instructor to force/encourage you to use a better process and to experience the benefits of doing so.

Single-part assignments, on the other hand, are used to help you become more independent. That is, they give you the freedom to choose a process and, often, experience the disadvantages of bad processes.

One way to combine the two is as follows.

Have you complete one or more single-part assignments that allow you to use a bad process (i.e., make mistakes).
Have you complete one or more multi-part assignments that force you to use a good process.
Have you complete one or more single-part assignments that give you the opportunity to demonstrate that you have learned the importance of using a good process.

This may happen within one course or across multiple courses.

4 Grading

Programming assignment are graded for two primary reasons. First, the grade is an assessment of your mastery of the skills and knowledge required to complete the assignment. Second, the grade is an inducement for you to complete the assignment (i.e., experience has shown that most students do not complete ungraded assignments) and, hence, learn the material.

4.1 Partial Credit

Programming assignments are sometimes graded on an all-or-nothing basis and sometimes partial credit is awarded. There are reasons for both.

All-or-nothing grading helps students realize that "almost working" is often not good enough. For example, would you fly in an airplane in which the avionics software is "almost working"? It also helps students realize that "almost working" is a nebulous concept. If, in fact, a software product is "almost working" then it shouldn't be hard (and shouldn't take much time) to make it "work". However, students often say that something is "almost working" when, in fact, there is still a considerable amount of work to do.

Partial-credit grading, when done carefully, helps students assess the topics they do and don't understand. Good partial-credit grading schemes award credit for particular concepts, not for the percentage of the assignment that was completed.

Partial-credit grading should not be confused with effort-grading. While everyone appreciates effort, in computer science/software engineering it is expected, not rewarded. In computer science/software engineering, results are rewarded.

4.2 Style Points

Style is a very important aspect of code (as it is with other kinds of "writing" activities). Hence, most programming assignments have style requirements and style is considered when grading.

Because style is so important (e.g., it is very difficult to read code that doesn't satisfy style requirements) and because it is so easy to comply with a style guide, it is common to give a grade of 0 to programming assignments that do not comply.

5 Collaboration Policies

Different courses have different collaboration policies for programming assignments.

The main argument in favor of allowing collaboration on programming assignments is that it helps you learn. It does this by allowing you to learn by doing. That is, you can learn the material while you are using it. Collaboration can also reduce the stress associated with an assignment, allowing you to focus on learning rather than on completing the assignment so that your grade doesn't suffer.

There are two main arguments against collaboration. First, it makes it harder for the instructor to assess your ability to complete a "sizable" assignment (i.e., an assignment that can't be completed within an examination period). Second, it makes it harder for you to assess your own abilities. That is, you might delude yourself into thinking that you know something when, in fact, you don't, because someone else has really done the work. (This is particularly problematic in programming courses, because later courses rely heavily on prerequisite courses.)

Hence, even in a course that allows you to collaborate, you should do so sparingly and in ways that are appropriate and help you learn. Excessive and/or inappropriate collaboration will not help you in the long run, even if it seems to in the short run.

Of course, it is your responsibility to know and follow the collaboration policy for a particular course. See the course "Policies" page for more information about this course.