How do I keep my sanity with an overdue programming assignment?
October 25, 2010 5:37 AM   Subscribe

How do I keep my sanity with a long overdue academic programming project? Especially with debugging?

I have a programming assignment for college which is long overdue. It was originally estimated to need about two or three months, now I've been working on it over six months. There may have been a mistake in assigning this, since the professor who chose this topic usually works with post-docs with more experience. I'm not one of them. Fortunately, my mentor has been very understanding, but I need to be absolutely finished in about a week. I don't know if I can make it, because of some intractable bugs I've not been able to fix. After that, I will need about a month to write my report of about 50 pages.
About yesterday, I noticed some worrying signs regarding my sanity: I started to have favorites among my (Java) classes, had trouble sleeping ("Can't sleep. Must code. This one bug.") and now have a royally messed up sleep cycle. This does not help my productivity at all.

Do you have any ideas how to keep productivity high despite being fed up with debugging and having lectures to attend? Any small Zen rituals to avoid loosing touch with reality?
In addition to that, if I have some bugs I can't fix, should I mention them in my report?

The programming language is Java and I'm using Eclipse. This is my biggest project so far in terms of LOC and time.
posted by Triton to Computers & Internet (13 answers total) 2 users marked this as a favorite
 
Talk to your mentor about adjusting the scope of your project. Or perhaps break your project into smaller pieces that can be finished quickly and independently. That way, if you get stuck on one piece, you can move on to another part of the assignment and still be productive.
posted by Blazecock Pileon at 6:04 AM on October 25, 2010


Best answer: Seconding scope change.

If you're not already using one, you may find a progress tracking package helps you keep the bugs sorted out and gives you a sense of scope and progress. FogBugz doesn't have a huge amount of overhead, it helps give good estimates of when you'll be finished, and it's free for one or two person groups. You can plug the sections of the report in there, too.

Listen to your body on sleep cycle. I've finished many a semester in my day almost entirely nocturnal, because that's what worked for me.
posted by Homeboy Trouble at 6:12 AM on October 25, 2010 [1 favorite]


Best answer: When it comes to debugging, I find that talking to an outside person about the problem is immensely useful. Maybe even someone who can suggest ideas to track the bug down. Otherwise I quickly enter a circular loop of frustration. Is there anyone in your professor's research group who you could chat to?
posted by spaghettification at 6:15 AM on October 25, 2010


Response by poster: Thanks for the FogBugz hint. I really would have missed the student edition.

I'm not sure a scope change would help, since most of the code has already been written. But maybe a bit refactoring is in order.
posted by Triton at 7:17 AM on October 25, 2010


What is it about the report that's going to require a month to write? That seems like an awfully inflated timeframe for such a document of that length.
posted by toomuchpete at 7:18 AM on October 25, 2010


Response by poster: toomuchpete:
A lot of explaining the math behind the algorithm, proofs of correctness, proofs of asymptotic time requirements and multiple versions going back and forth. I thought it might be faster, but 4 weeks was the estimate from my supervisor.
posted by Triton at 7:40 AM on October 25, 2010


Can you work on the programming and the write-up concurrently? Writing about the project may help you identify potential sources for your bugs and being able to switch between writing and coding might make it easier to stay focused on your project.
posted by martinX's bellbottoms at 8:03 AM on October 25, 2010 [1 favorite]


Best answer: Still think that's way too long unless you're talking about including time for revisions to go back and forth with some sort of reviewer, but . . .

You probably need to take a step back, evaluate what works, what doesn't work, why various things don't work, what ideas you have for fixing the bugs, and so on. Then turn a very critical eye toward each of those bugs and prioritize them. If you only have a week but you have two week's worth of work, you're just not going to finish it all, so rather than flailing around, organize your work and make that one week as productive as possible.

The goal is always to have bug-free code, but software of any complexity is almost always going to have bugs.

I don't know about your professor, but if there was a bug in the program, and you understood why it was there and how you could fix it -- either by applying a whole lot more work, or by changing the way you approached the problem from the beginning -- that'd probably be worth about as much to me as the bug being fixed.

At some point you've just got to put your nose down and get as much done as you can. Time you spend stressing out about the amount of time you have left is time you're not spending working.
posted by toomuchpete at 9:34 AM on October 25, 2010


The people:
At this point this is a people problem, more than a coding problem. You need to re-negotiate and be firm. "I cannot get this project done on time. I need more time, and reduced scope." Define exactly what you know you CAN do, and offer it up.
posted by jander03 at 1:47 PM on October 25, 2010


Best answer: It's impossible to fix all of your bugs in a week, but you have to do it anyway. To stay sane, set a timer when you start to work on a bug. If after an hour it beeps and you don't have a good plan for solving the bug, walk away from your computer for five minutes, and think about what a good plan would be. Really think about nothing but that for five whole minutes (by the timer). If you come up with any solutions while thinking, don't dwell on them. Write them down on paper, then keep thinking about other possible solutions.

If it's late in your local night (i.e. you might be getting tired), set a timer every 30 minutes. Each time it beeps, evaluate whether you're making progress. If you're not, go to sleep.
posted by novalis_dt at 6:43 PM on October 25, 2010


You've been working on this for six months, honestly I'd just stop right now. Your supervisors won't get a working program, but that's what they get for assigning something two and a half times bigger than they were supposed to. Your report will just have a bigger than usual 'future work' section at the back where you outline what still needs to be done to be finished. If you can show that what you have done is logical both in planning and execution and also show that you've though about where to go next (including a list of the specific bugs outstanding), then that should be enough.

Look at scaling down your report too. Write about what you've done and why, but don't go into a lot of detail about background theory etc. This is (I'm assuming from the time scale) an undergraduate project so writing a full dissertation isn't necessary. Spend your next week sorting out the actual state of your project, documenting what you've done, what's still broken, how it can be finished - then just start writing.

Supervisors who have no grip on scope and assign too much work piss me off. The mess you've got into isn't your fault, your supervisor should have known better. It's time to draw this to a close, and if that doesn't include making the actual program work then tough luck to him.

(And yes, I know people who passed their Computer Science honours dissertation with a partially coded project, sometimes that's just how it ends up. If they want it finished they can assign that to the next student.)
posted by shelleycat at 9:22 PM on October 25, 2010


Response by poster: Your advice has been very helpful.

I used FogBugz to manage and prioritize my bugs. This and the timer method helped immensely to avoid loosing track. I didn't have anyone to chat to, but I wrote down my thoughts about a problem when I could.
I'm now pretty sure I found the cause of every bug, I fixed some of them and could fix the others given time.

Now, I'll start writing and only touch the codebase again if I find out I need a certain feature for my report.

I should note the professor who assigned the project and the supervisor who reads the reports are two different persons.

I'll keep you updated about the result.
posted by Triton at 8:28 AM on October 29, 2010 [1 favorite]


Response by poster: In case anyone is still reading this:

I left some bugs in, proceeded with the report and finished, after several iterations, in January.
posted by Triton at 6:15 AM on May 19, 2011 [1 favorite]


« Older Should we ditch our fixed-rate mortgage?   |   Name the film Newer »
This thread is closed to new comments.