An exercise in utility

Question

We have an incentive grading scheme for programming labs such that students get 89% for submitting a program that meets the basic requirements of the assignment, if submitted on time. To get the "extra credit", they have to add something useful on to the basic requirements, still submitted on time. We did this because we were having two issues in the classes:

1. Students were just doing the bare minimum
2. They were handing things in late

But, in a weird twist on Pareto optimization they now spend the first 89% of the time trying for the extra credit portion, and the remaining 89% of the time just getting the bloomin' thing to work correctly (Parkinson's Law).

I usually fail to anticipate this, so when I say, for example: "use Bootstrap to get your web page to look basically like this..." and the first thing they do is go to the "designer screen" in Visual Studio and start dragging, resizing, re-positioning, changing fonts, colors, etc, I am stymied. (It does not turn out well.) I was thinking that they would make some programmatic improvements to the very simple example, since most of the basic code could be copied right out of the textbook anyway.

Is there a way to encourage the students to get something working first, then enhance it? Is a grade incentive the wrong way to go about that? I suppose it is really down to me, as it says in the Art of War: "If the instructions are not clear, if the orders are not obeyed, it is the fault of the general." Good thing I do not have 160 students.

Answer 1

Actually, there are two questions here. I'll answer the obvious one first. You can fairly easily solve the perverse incentive problem by having two due dates: one for the first 89% and a later one for the rest. If you have ideas about what they should do for the second part, don't reveal them until they turn in the first part. You needn't necessarily even mark the work after the first deadline, but you can, if desired.

After the first deadline you have a version of the project. You can compare it with the second version to see what changes/enhancements have been made. In situations like this, I usually have students turn in work on paper and in the second version, mark changes (highlight markers) so that those changes are obvious.

The second question is how much you want to encourage student "creativity" anyway. It isn't always good to let students loose without specific direction. There are two kinds of creativity: the what and the how. In the real world, it isn't normally the programmer who is responsible for the what. That is up to the Customer/Client/Boss/Organization. The creativity on what belongs to them. On the other hand, creativity (i.e. excellence) on the how is the key attribute of a good developer. For most assignments that is what you should be looking for. Do they understand the algorithms? Can they implement them efficiently? Is the code clear and maintainable? Is it tested and correct?

So, I worry that if you just give an incomplete specification of the work and expect them to use their own creativity around what should be done, that they will get the wrong ideas about building things. As others have said in answer to other questions here, going outside your charter can be seen as a problem, not a blessing. See this, for example: https://cseducators.stackexchange.com/a/4539/1293

On the other hand, teaching creativity is also a goal of education and there should probably be one or more courses, or at least projects, where students do get to conceptualize, design, and build something interesting. But don't let them get confused.

---

Caveat. Those who work at startups that define their own product have a different view. There, it is often the case that programmers participate in defining the product, but that isn't the common case.

Answer 2

If your real concern is the first one stated (doing just the minimum), there is another solution, though a bit more complex. Read the wikipedia article on Minimum Viable Product for some ideas. You don't normally want them to do everything for a product, of course, even a minimal one, but the idea of a Minimal Correct Solution can be adapted from that. Decide what that minimum acceptable solution is and then give an assignment in which a medium passing grade will be assigned for that. Give it a complete specification of just that part. You can have an early deadline for that part of the larger/complete project.

In the second (and perhaps subsequent) stages, give additional specifications for enhancement of that minimum into a more complete and pleasing whole. Assign additional points/percentages for those additional enhancements. You can make the add-ons sequentially, but it is sometimes also possible to offer them a set of independent enhancements that can be done or not and possibly done in any order.

If they do just the minimum they get, perhaps, an acceptable grade, but they get guidance on what enhancements would be valued. As I suggested in my other answer here, you can have them mark changes in the second and subsequent versions to make grading quick and painless.

Note that this solution also requires more than one deadline, perhaps with feedback between them. But this will also avoid the perverse incentive problem.

Answer 3

I thought Pareto was 80/20!

Could you start from the platform of, get the program working? I mean, that in itself is an achievement. The extra credit can be on offer to the 'bug hunters'; work out all the bugs and get the program working perfectly.

To be clear: get the program working, but with bugs = 80%. You then have a 20% margin where you can get the students to submit proof of bugs found, and how they resolved them. A perfectly working program with no bugs? 100%. How you grade between the 80 and 100 delimiters is up to you: an extra 4% for each problem found and resolved perhaps? They'd have to submit proof.