ICS 32A Fall 2017
Project Guide


The projects


Goals

This quarter, you'll work on seven programming projects — two warm-up projects and five that are full-sized — that will build your knowledge of Python programming, assuming prerequisite coursework where you learned introductory programming in at least one other programming language previously. 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 of the projects (except for the first of the two warm-up 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. 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 projects will offer you the option of working on in pairs using a technique called pair programming, while the others will require you to work individually, a skill that I'd also like to see you begin to develop this quarter.

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. As the quarter progresses, you'll find that you're being asked to write more code, to write more of it from scratch, and to build programs that are made up of a progressively larger number of interacting parts. There is a method to this madness: Not only will this course strengthen your ability to write individual Python functions and classes, but it will also begin to cultivate your understanding of the design of ever-larger programs. Your projects will be evaluated based not only on how well they work, but also on how well they are designed and written. Poorly-written code that works will be viewed critically, just as well-written code that has bugs will be. Don't worry, though; we don't presume that you've had any experience designing your own programs before, 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 feel empowered to follow your own interests and explore new libraries and new problem domains that excite you.


Pair programming

What is pair programming?

For some of the projects in the course, you will have the option of employing an approach called pair programming. Pair programming is not just two programmers working separately on a task, with the work divvied up between them. In pair programming, two programmers share one computer. One is the driver, who controls the keyboard and mouse. The other is the navigator, who observes, asks questions, suggests solutions, and thinks about slightly longer-term strategies. The two programmers switch roles about every 15-20 minutes, the goal being that both partners have complete mental ownership of all the work that's done, even though only one person at a time is typing. This obligates both partners to communicate with one another about what they do and do not understand, with each partner bringing the other one up to speed when necessary. In so doing, both partners have a firmer grasp on what they're doing and, at least as importantly, why they're doing it that way.

A pair of programmers (as described here) nearly always beats the stereotypical solitary loner of similar ability. For projects that allow pair programming, we'll be requiring you to follow this model if you choose to work with a partner, and will be keeping track of students who aren't; we reserve the right to penalize students who routinely refuse to work as pair programmers, or who refuse to do it as described here. Pair programming involves shared responsibility, and we expect both partners to bear their share of it.

While some industry software development environments use pair programming to (documented) good effect, the reality is that individual programming is still a widely-used strategy in the real world. Many future courses that you'll take here will require individual work, as well. Study after study shows that working in pairs at this stage of your development as computer scientists will strengthen your abilities to work individually, as well as in pairs. Still, we'll only use pair programming for a portion of this course; some projects will require individual work, to acclimate you to the demands of future courses and/or future employers. Rest assured that successful pairing to this point — if you've been working alongside a partner, sharing fully in both the driving and the navigating — will have made you more ready to work individually than you would have been had you been working individually from the beginning. Also remember that the course staff — me, the TAs, and the lab tutors — are here to help!

Pairing rules

For each project in which you pair up, you will be required to select a lab partner who is also enrolled in your lab section. (For a variety of logistical reasons, pairing of students in different lab sections will not be allowed under any circumstances.) Additionally, you will be required to partner with someone who you have not partnered with previously in this course.

Pairing advice

The best time to find a partner is at the ICS 32A Help Center during your scheduled lab section. Don't be shy! Talk to people! (Part of the benefit of a university education is the social network that you'll have when you're finished. True story: Every job I've had since I enrolled as a student at UCI, including this one, was connected fairly directly to my UCI experience.) If you're having trouble finding a partner, talk to your TA, who will be able to help you find one.

It's not a bad idea to find a partner whose skill level is similar to yours, or one who is more skilled in areas where you are less skilled. This won't always be possible, and it's sometimes hard to compare skill levels at all, but students tell us (and other data support) that pairs are most productive when the partners are at about the same level.

Still, people often pair up with another whose skills and abilities are different. The differences may be great or small; one member may have more strengths than the other. But this is exactly like most real-world working situations. Part of accomplishing a task is to get the most out of each member and make each member stronger and more productive on subsequent tasks.

A clearly stronger partner may feel frustrated or slowed down by the other partner, but the stronger partner benefits from the teamwork in many ways: The other partner's requests for clarification often point out flaws in the approach or solution, the teamwork skills gained have great value in the job market, and the exercise of providing a clear explanation solidifies and deepen's the explainer's own understanding.

The less strong partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does individually. It is part of each partner's job to understand the whole task; that means asking questions when necessary and answering them when possible.

Am I expected to work with my partner outside of the scheduled lab sections?

Generally, yes. You'll almost certainly need to spend some time working outside of scheduled lab sections, as your scheduled lab section constitutes only four hours per week, but some of the projects may take substantially longer than that.

Understand, though, that you're not doing pair programming if you're in separate locations talking via instant messages, sending code back and forth via email, or even talking on the phone. Pair programming requires both partners to be in the same room, sitting behind the same computer, with one acting as the driver and the other acting as the navigator. I'm not unsympathetic to the fact that scheduling time to work together is difficult, but it's a requirement of the course if you opt to work with a partner, so you should be aware of it up front.


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 are often many 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 goals. Since they're an integral part of our work — they dramatically raise the limit 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.

Re-evaluation of your work

As projects are graded, you will receive scores and feedback on each in an email from your TA. If you believe that you've been graded unfairly, your first move is to contact your TA and discuss the issue with him or her directly, as your TA is more familiar with the details of the grading of your work than I would be — the first thing I usually do is to contact the TA, anyway. Most issues are resolved this way. Note that we will not reconsider the rubric used to grade your work afterward, but if it was applied unfairly or incorrectly, we can consider an adjustment.

If, after this, you still believe that you haven't been treated fairly, you are welcome to raise the issue with me and I can arbitrate, though I should point out that it is relatively rare that I overrule a TA's judgment. I've communicated a fair amount with the TAs about grading ahead of time, so they're generally acting on my instructions, so I don't find very often that I think a TA has graded work unfairly.

Note, also, that we will not be willing to regrade your work by having you demonstrate it on your own laptop or device. We are only willing to grade what was submitted before the deadline, and we are only willing to grade your work in the way that we graded everyone else's, which means we must retain control over what files we grade and in what environment we grade them.


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 with no penalty — 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. However, we generally require to keep up with the due dates as assigned, and we do generally assign a penalty for work submitted late.

Submitting late work

Aside from the "one-time" late submission, described below, late work is accepted according to the following policy:

Full or partial hours are counted. So, for example, a project submitted at 3:15am the morning after an 11:59pm deadline would be subject to a 4% penalty, because it was submitted 3-1/4 hours late (i.e., three full hours plus a partial one). In that example, if your score on the project would have been 27/30 ordinarily, it will be reduced by 4% and become 25.92/30 instead.

This means, in general, that a project submission has at least some value for 99 hours beyond the stated deadline. At the 100th hour, the project has no value remaining.

The "one-time" late submission

To accommodate the occasional unforeseen issue, we do also allow a "one-time" late submission:

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

In general, this procedure is automatic and does not require negotiation or notification; we will apply this consistently to everyone as described above. The goal is that this should accommodate the unforeseen issues that might otherwise prevent you from finishing a project on time, while freeing course staff to focus on helping students to learn and improve.

Does this policy apply to Project #0A and Project #0B?

Project #0A and Project #0B are not covered at all under this policy. They must be submitted when due in order to be considered at all.

What to do if you're chronically late

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 project or chronically, please contact me and we can talk about how best to approach the problem. It's important to contact me sooner rather than later; earlier in the quarter, there are a lot more things I can do to help than there are in the tenth week or after the final course grades are determined.


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, nor is there any remedy (outside of the late policy described above) for forgetting to submit your work at all.


Development environment

The machines in the ICS labs already have the required development environment for ICS 32A 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 Project #0B 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 32A 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, 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.

All violations of academic honesty policies will be reported to the UCI Office of Academic Integity & Student Conduct (AISC) and will trigger an administrative procedure, which is described on their web site. Additionally (and at least as importantly), you can receive a course grade of F — as a number of students in these courses do, because of this issue, every quarter — without the option to drop the course to avoid the grade. A single documented case of academic dishonesty may also have other ramificiations, such as precluding you from switching into computing majors, registering for computing minors, joining the ICS Honors Program, and graduating from a computing major with honors. All of this is University and Bren School of ICS policy and is not subject to negotiation.

Knowing when you're being dishonest

I've been asked by students how they know when they're crossed the line between asking for help and being academically dishonest. To me, there is a fairly straightforward way to know the difference. Did you actually write the code in question? That's not a matter of whether you typed it in; that's a matter of whether it was you who wrote it (i.e., it is comprised of your own ideas about how to solve the problem, how to organize the solution, and so on).

The easiest way to determine whether you've crossed the line is whether your work was driven by someone else's existing solution. Here are some examples:

In my view, this really isn't that complicated. We require you to do your own work, because that's how the learning is done in this course. A large part of what you're learning to do is to design and write programs, a skill that can only be built by designing and writing programs. You have to make the decisions about what to do next, how to organize your program, and so on. If someone else is making most of those decisions for you, you're not building the skills necessary to be ready for the courses that follow on from this one. And, from the standpoint of academic honesty, if someone else is making most of those decisions for you, that's plagiarism.

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 this course (or one or more important topics in previous coursework) on which later topics depended, 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 overall life 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. As upwards of 10% of my students (who have cheated like this) can attest, 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.

And, in general, some students won't pass this course with a C or better this quarter, and won't be moving on to ICS 33 next quarter. And that's not as disastrous as it sounds. Most students who get less than a C in ICS 32A will be able to take ICS 31 and 32; most of those who take the course again pass these courses the second time around, with their feet firmly underneath them and ready to move forward.

Sharing your own solutions online

Some of our past students have wanted to post their own solutions to their projects online, with the goal of helping others or just showing off work that they were proud of. This is also problematic from an academic honesty perspective, because many or all of the projects you're working on will be reused in a future quarter; good problems are good problems, and I don't rebuild five new projects every quarter. Given that, posting your prior work online will absolutely lead to other students finding it and plagiarizing it — this is now one of the more common root causes of plagiarism cases that we find.

I can appreciate, of course, that you might want to build a portfolio of work to demonstrate your skills as you build them, and I'm not unsympathetic about that. However, the reality is that posting solutions to first-year coursework is very unlikely to be of use in job searches or other professional scenarios. I've asked a number of hiring managers over the years, including the ones I work for in my industry career, and have universally received the same response about it: Hiring managers generally aren't interested in seeing prior homework. Projects in courses like this one are sanitized, in the sense that they're problems that have been designed to be solved using techniques just taught, with the requirements clearly spelled out, and with few enough rough edges that a large number of students can solve them without encountering roadblocks that can't be overcome. Real-world work isn't like this, as it turns out. Figuring out what needs to be built is as important as figuring out how to build it. Building a portfolio is best done with your own solutions to your own problems, containing things you've written to scratch your own technology itches or explore concepts that you wanted to learn more about on your own.

So, in general, despite the fact that you may be proud of the work you've done, you need to understand that there is a very strong likelihood that the only thing you'll be doing is enabling future students to plagiarize your work — and quite possibly becoming embroiled in the investigation yourself and being reported to AISC — while not accomplishing much of anything positive for youself.

Do not share your prior solutions online.