ICS 33 Fall 2024, Project Guide

The projects

Goals

Throughout this quarter, you'll work on five programmming projects. The first is a warm-up project that will familiarize you with the development tools we'll be using, while relying on your existing Python programming skills to allow you to hit the ground running. The remaining projects are focused on applying the new Python skills that you'll learn in the course, as well as some additional skills that lie beyond Python, but that Python will help us to use effectively.

Having already taken prerequisite coursework that taught Python and the use of existing software libraries, you'll have already developed the ability to work in realistic problem domains that are initially unfamiliar, so we'll be able to continue doing likewise this quarter, even if it's not the central focus of the course. Programming skills are intensely practical, so we'll try to give you problems that meet practical objectives, even if they're also meant to allow you to exercise particular new Python or program design skills.

We'll also leverage a somewhat more professional set of software development tools, including a full-fledged integrated development environment, automated testing with test coverage measurement, and a version control system, all of which will improve your ability to work on larger-scale projects, while planting seeds that will sprout in the not-too-distant future when you might find yourself doing collaborative work (for courses, for fun, or for profit), even though group work isn't on the docket this quarter. For those seeds to sprout, though, you'll need to plant them, which means that you'll need to embrace the tools we're using this quarter, even if they feel unfamiliar at first; unfamiliarity just means you're learning something new, which is why you're taking a course like this in the first place.

By the end of the quarter, when you've successfully worked through all of these projects, you'll likely find that your skills will have improved across multiple dimensions: your Python programming skills, your ability to design and test programs, and how well you organize a longer-term piece of work incrementally.

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. You know from your prior experience that 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, all of which were underlying themes of your prior coursework, and which we'll continue to improve upon this quarter. Since they're an integral part of our work — they dramatically raise the limit on the size of the 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. To the extent that automated testing is required, you'll need to have completed it. To the extent that you're required to follow an incremental process, you'll need to have followed it. Your completed 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. Docstrings must be included on every function, and type annotations are a good addition when there is a way to specify them concisely in Python (though some of what we're doing this quarter will be dynamic enough that this will be more difficult than it was in the past, so this is not a hard requirement).
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

See the Course Reference for an explanation of what to do if you have a question about how your work was graded after a score has been reported to you.

What code can I use that was written by someone other than me?

For the most part, we'll be requiring you to implement your own solutions. You can use the Python Standard Library where appropriate — and where I haven't specifically disallowed it (usually because it's a way to avoid one of the key learning objectives of a project) — but you will otherwise not be able to use code written by anyone else other than you.

Notably, this includes third-party libraries (i.e., those that are not part of the Python Standard Library), which are strictly off-limits except where specifically allowed. Colloquially, if we have to install something other than Python in order for your program to work, it's considered off-limits, unless specific permission is given in the project write-up.

It's worth noting that this also disallows the use of automatic systems, such as generative AI systems like ChatGPT, from producing any part of your solution, because that, too, would not be code written solely by you.

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, or you have three midterms and a paper due the same day, or you have a sudden outside commitment that can't be avoided, or you have an unanticipated illness. 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:

You may submit late work, subject to a penalty of 1% of your final score per hour beyond the deadline.

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:

Each student is permitted to submit any one project up to 99 hours late with no penalty, 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.

You are not required to notify us in advance — in fact, in all honesty, we'd prefer that you didn't. (There are a lot of students in this course, so that would represent a lot of extra work for us.) We'll be looking for submissions beyond the deadline of each project, so yours won't be lost in the shuffle.
There is no grace period after the due date. If you submitted your files at 12:08am (or even 12:00am) for an 11:59pm due date, your submission falls under the late policy and would be considered one hour late. No exceptions!
If any one file is submitted beyond the due date, the entire project is considered late and, hence, it falls under the late work policy.
If a project is submitted before the due date, but one or more of its files are resubmitted (or added) after the due date, the entire project is considered late and, hence, it falls under the late work policy.
If you submit more than one project late this quarter, we will automatically determine the best possible outcome for you, so that you get the maximum benefit from this policy. For example:
- Suppose you submit Project 1 five hours late and your score would have been 10/30 before taking lateness into account.
- Suppose you submit Project 2 two hours late and your score would have been 30/30 before taking lateness into account.
- The late penalty on Project 1 would be 5% of 10 points, or 0.5 points.
- The late penalty on Project 2 would be 2% of 30 points, or 0.6 points.
- Given these numbers, we would apply the "one-time" exception to Project 2, since it will provide you the most benefit (0.6 points instead of 0.5).
Just to be clear, the policy works by "refunding" the largest late penalty at the end of the quarter. That's it. Nothing can be submitted after the 99-hour late deadline. In particular, be aware that other scenarios are not applicable under the policy, such as these:
- Splitting the 99 hours up on multiple projects (e.g., one project 40 hours late and another 50 hours late).
- Submitting something 110 hours late and applying the 99-hour policy to it by subtracting 99 hours from the late penalty.

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.

On which project should I use my late policy?

Ideally, you wouldn't use it at all. The goal is for this policy to act as a safety net to catch you when unforeseen things happen, not as a way to engineer extra time on a particular project that you've anticipated is the trickiest one. Once you've used your safety net, you won't have one underneath you, and we will not generally be willing to negotiate a new one just because something else unforeseen — something for which the late policy is actually intended — happened. Your choice will already have been made.

Does this policy apply to Project 0?

Project 0 is not covered at all under this policy. It must be submitted when due in order to be considered at all.

Does this policy apply to the reinforcement exercises?

No. The reason for the reinforcement exercises is to keep you on track as we proceed through the course, so those are also not covered by the late policy.

Is illness handled separately from the late policy?

Generally, no. If you've used your late submission on, say, Project 2, then catch a cold two days before Project 4 is due, that illness would fall under the late policy, which you would already have used, so we won't then be willing to renegotiate Project 4's due date with you. We can understand that the illness was unanticipated, but that's the whole point of the late policy in the first place: to protect you against an unanticipated issue.

So, again, your best bet is to plan not to use the late policy, so that it's available to you when something unforeseen happens.

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 in our Canvas course space. Each project will specify what should be submitted and how. Understand that we will only accept projects submitted to Canvas; we do not accept printed copies of your projects, nor do we accept them via email or any other online mechanism under any circumstances.

There are a few additional rules to be aware of.

When grading your program, we'll grade only the most recent commit on the main branch of your most recent submission, except to the extent that we'll examine prior commits when evaluating your overall process. We will not negotiate about which commit or submission will be graded, or, for example, grade multiple of your submissions and/or commits and "take the highest score."
You're responsible for submitting the version of your project that you want graded prior to the deadline. Contacting us afterward and telling us that you accidentally submitted the wrong version will not be grounds for a resubmission under any circumstances.
You're responsible for making a submission in order to receive credit, which means you'll want to be sure that you've remembered to submit your work and verify in Canvas that it's been received. A later claim of having forgotten to submit your work, having misremembered the due date, or claiming that Canvas has somehow lost it will not be grounds for a resubmission under any circumstances.

Development environment

We'll be using a particular set of development tools this quarter, which you'll need to obtain and install. (Note, too, that they may be different from the tools you used in previous courses.) Please refer to Project 0 for instructions on getting precisely the right versions of the necessary 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.

Academic honesty

The policy

As a student enrolled in ICS 33, 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 work on projects and reinforcement exercises is expected to be completed solely by you. Working in larger groups and/or sharing of code or solutions between students 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. Note, also, that this disallows the use of automatic systems, such as generative AI systems like ChatGPT, from producing any part of your solution, because that, too, would not be code written solely by you.

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 Final Exam is also expected to be an individual effort. Dishonest behavior during an exam will not be tolerated.

All violations of academic honesty policies will be reported to the UCI Office of Academic Integrity & 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 my 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:

If you ask someone to help you resolve a compile-time or run-time error in your program, so you would understand what the error meant, that's fine.
If you ask someone for help on a project and they responded by giving you a copy of their work, you already have one foot on the line the moment you receive it. If I were you, I would delete it, or not ask for it in the first place.
If you ask someone else to help you understand a concept like recursion or the use of pointers, and the other student suggests a way you might think differently about the problem you're solving, that's fine.
If you ask someone else to help you understand how to solve part of the project, and the other student brings up a copy of his or her solution and walks you through it — even if you don't look at it yourself — you've crossed the line.
If you obtain a copy of someone else's solution to a project and you refer to it and use it to drive the work you're doing — in whole or in part — you've most definitely crossed the line. Copying someone else's code, typing in someone else's code, taking someone else's code and cosmetically changing it to make it appear superficially different are all (obvious) examples of academically dishonest behavior, yet upwards of 10% of my students are caught doing this — and sanctioned for it — every quarter. Please don't be one of them.
If you provide someone with a copy of your work and they submit it as their own, you are also involved in academically dishonest behavior, and you should be aware that you can also be sanctioned for this, just as the other student can. Your best bet is not to share your work with other students, yet a not-insignificant percentage of my students are caught doing this every quarter, as well.
If you ask a generative AI system to write a solution to some or all of an assignment, you've crossed the line.

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 ready to take follow-on courses yet. And that's not as disastrous as it sounds. Most students who get less than a C in ICS 33 take the course again; most of those who take the course again pass it the second time around, with their feet firmly underneath them and ready to move forward.

Reusing one's own work

If you took the course during a previous quarter, it's worth noting that reusing one's own work is not defined in this course as plagiarism. If you originally wrote it, it is not plagiarism to reuse it.

That said, taking a course a second time and submitting one's own work without doing things again from scratch is usually a recipe for failing the course the second time.

I'd ask myself whether reusing your own work, in general, is a good approach. If you failed the course previously, it means there are substantial parts missing from your understanding, and they could be strewn throughout the course, including buried in the details of assignments on which your scores were high the last time.

My suggestion is to pretend like you haven't taken the course before and do everything from first principles. Otherwise, you may find yourself reaching the same points in the course with the same misunderstandings you had before, which will ultimately lead to the same outcome.

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 ones I've worked 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, during or after the quarter.