ICS 33 Summer 2013
Project Guide

The projects


This quarter, you'll work on four programming projects, building on your knowledge of Python programming from prerequisite coursework (ICS 31 and ICS 32, or equivalent work elsewhere). Collectively, the projects are intended to give you the opportunity to improve your skills in a few ways, with such overall goals as these.

As you might expect from the goals above, all five projects will be written in Python, and each will explore new territory — new Python language constructs and techniques, new libraries and real-world problem domains, and/or new areas of computer science. You will surely discover that the projects increase in size and difficulty as the quarter goes on, but if you put the appropriate amount of effort into each of them, get questions answered along the way when you're stuck, and understand afterward what you did and why it worked, you'll find that your skill level will rise steadily to match the rising difficulty.

Some of the projects will include a starting point, in the form of documented code that I provide to you as a means of getting started, though you should expect that not all projects will include one, and that you'll generally be asked to write more code, code with a greater level of complexity, and to write programs that are made up of a progressively larger number of interacting parts as the quarter progresses. This is consistent with our goal of improving your abilities to write programs both "in-the-small" and "in-the-large," developing key skills that will allow you to write solutions to "real" problems that you find interesting and exciting.

As always, we don't presume that you've had more experience designing your own programs than you will have gained in prerequisite coursework, so we'll be providing many examples and plenty of help along the way.

By the end of the quarter, when you've successfully worked through all of these projects, you'll be surprised at how much your skills have improved. And after the course is over, you should be able to tackle a broader collection of problems than ever before.

Evaluation of your work

Evaluation criteria

Each of your projects will be graded using a 30-point scale. As you work on your projects, it is naturally your primary goal to write a program that behaves as specified, meeting all requirements specified in the project write-up. However, writing a correctly-working program is not your sole objective. As you've no doubt already seen in previous coursework — and we'll see even more clearly as you begin to attack problems that are larger and more complex — there is a variety of ways to solve a programming problem, but some are more manageable than others. Some approaches are simpler, some more complex; some yield code that can be read and understood more easily by yourself (and other people!) than others; some are easier to change without requiring changes that cascade throughout your program than others; and so on. We'd like you to focus on writing programs that tend to be simpler, more readable, and more changeable, and we'll discuss techniques throughout the quarter to achieve those goal. Since they're an integral part of our work — they dramatically raise the bar on the size of program you can write — these qualities are assessed in the grading process.

Each of your projects will be evaluated on the following basis.

Quality Value Description
Correctness and Robustness 20 points When the program is given valid input, does it generate the correct output according to the specification in the project write-up? Is the output spacing correct, if this is an issue? In short, does the program do what it's supposed to do for any input that meets the project specifications? When the program is given unusual or erroneous input, is it handled gracefully? Programs should not crash in these situations; they should, for example, print informative messages to the user, ask the user for alternative input, or find another way to continue executing (if possible).
Quality and Design 10 points Particularly awkward, cumbersome, or inappropriate ways of approaching problems will not score as highly as cleaner, better-designed ones. Your program should be divided into logical parts, with large functions or classes divided into smaller ones, each encapsulating a single idea or task. Different kinds of work — interacting with a user, calculating results — should be handled in different functions or classes. Comments should be used to make a program clear to the reader (though it should be noted that good modularity and well-named identifiers make the commenting burden significantly lighter). Identifier names should be chosen to reflect their role; the names should be meaningful to the reader. Type annotations and docstrings must be included on every function.
Total 30 points

Some projects may be graded somewhat differently; if so, alterations to this grading scale will be included in the project write-up.

Late work

Things happen and ten-week quarters can be unforgiving. It's not unreasonable to expect that you may find it difficult to finish one of the projects on time, even if you're on top of things most of the time. I get emails often from students, saying things like If I just had one more day to work on this, I'd get it done! On the other hand, being consistently behind is a recipe for struggle in this course; we'll be moving quickly, and it will be progressively harder to catch up the farther behind you get.

The best balance between these two realities is that everyone is allowed to have a tough time with a project once this quarter — maybe you underestimated the difficulty of an assignment, maybe you have three midterms and a paper due the same day, maybe you have a sudden outside commitment that can't be avoided. For this reason, I'm offering the following late work policy:

Each student is permitted to submit any one project up to 48 hours late, with no questions asked about why and no prior notification required.

For the purposes of clarification, here are some additional details about how this policy works:

We'll be tracking this throughout the quarter and, of course, will not grant the extension to anyone more than once. But this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time.

Other than this, late work is not accepted in this course. However, partially complete work can certainly earn partial credit, so if you haven't completed a project and have already used your one-time extension, it's best to submit what you have before the deadline rather than submitting nothing.

Out-of-the-ordinary circumstances sometimes warrant exceptions to this policy; if you are faced with a problem that is preventing you from getting your work done on time, either on a single assignment or chronically, please contact me and we can talk about how best to approach the problem.

Submitting your projects

When you complete each project, you must submit it to us electronically. Follow this link for a detailed description of how to submit your projects. Understand that we will only accept projects submitted using the procedure described there; we do not accept printed copies of your projects, nor do we accept them via email under any circumstances.

You are responsible for submitting the version of your project that you want graded. We will grade the most recent submission that you made before the deadline. Accidentally submitting the wrong version will not be considered grounds for a regrade.

Development environment

The machines in the ICS labs already have the required development environment for ICS 33 installed on them; for those of you who want to do at least some of your work on a machine of you own, you'll need to make sure to install and configure the necessary software. Note that the tools we're using this quarter may be slightly different from the tools you used in previous courses, and you'll need to be sure that you upgrade to the right versions before proceeding.

If you're planning on using your own machine for at least some of your work, please refer to Assignment #0 for instructions on getting precisely the right versions of these components installed and configured properly for this course. While we will try to help if you get stuck, please be aware that we realistically cannot support each of your home installations, so you will be responsible for getting these tools installed and configured, and will need to use the machines in the ICS labs as a fallback if you're unable to do so.

Academic honesty

The policy

As ICS 33 or CSE 43 students, you are expected to know and follow the academic honesty policies of both the Bren School of ICS and the University as a whole. Please take a few minutes to read the policies, which can be found at this link.

All of your project work is expected to be completed solely by you (and your partner, on paired projects). Worker in larger groups and/or sharing of code between students that are not partners is not permitted. Note that "high-level discussion of course material for better understanding" is permitted and encouraged, but when it comes time to sit down and write code, that is expected to be done by you and you alone. All submissions are compared to one another using an automated plagiarism detection system. This system is extraordinarily good at finding similarities between submissions, even when there are superficial differences. (Note that we also compare your submissions to those submitted during previous quarters whenever one of these assignments was given during a previous quarter, so it is an exceedingly bad idea to turn in, or even refer to, code written by a friend of yours who took the course already.)

Since all of your work is expected to be completed solely by you (and your partner, on paired assignments), you will be held responsible even if you plagiarize only a small portion of someone else's work.

Academic honesty is a two-way street. Providing your code to other students for them to turn in as their own is not permitted any more than turning in someone else's code. Resist the temptation to give code to your friends "for reference." Based on my experience, I can say that your "friends" may very well betray you and turn it in, anyway, and then you'll have a lot to answer for.

Naturally, the Midterm and Final Exam are also expected to be individual efforts. Dishonest behavior during an exam will not be tolerated.

Violators of academic honesty policies are subject to the penalties described in the Bren School of ICS policy. They are also subject to an immediate course grade of F, and you will not be allowed to drop the course to avoid the grade. Also be aware that a single documented case of academic dishonesty may preclude you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors.

The lesson

Okay, so the moral of the story is that it's wise to avoid cheating. I believe that it's relatively rare that students enter a course with the conscious intent to cheat their way through it; why come to UCI if you're not planning to get something out of the coursework? So why do people cheat every quarter in every course? The answers vary, but here's the easiest way I can boil down the numerous conversations I've had with students caught cheating in my courses over the years: I fell behind and couldn't figure out how to catch up. Things happen and ten-week quarters are unforgiving. You might get sick, you might have issues crop up in your family, you might have misunderstood one of the earlier topics in the course on which later topics dependend, you might have an off-campus job that's demanding too much of your time, you might be trying to decide whether you're on the path you want to be on... Any of those things (and many others) can make it hard to keep up. You fall a little behind, you fall a little further behind, and pretty soon the situation seems hopeless. You're under pressure, temptation gets the better of you, and suddenly it seems better to submit someone else's work than to submit nothing. It's not.

If you feel like you're beginning to slip off course or things are getting beyond your control, the best thing to do is to talk to us sooner rather than later. We're here to help; we understand. But the reality of taking large-sized courses at a large-sized institution is that we're not going to know you're in need unless you tell us. If things are happening in your life, tell us; you don't have to be specific if you're not comfortable with it. Before the fact, there's often a way to work things out. After the fact, it's usually too late.