Planning, designing, and writing the first iteration of our project was a rocky but helpful experience. As most college students know, group work is often one of the more volatile types of school work one can experience. During this assignment, I found that having a partner similar to me not only didn't do much to improve that, but harmed it. The primary problem is that I and my partner are both procrastinators. We tend to start projects later than intended but spend a large amount of time working on it those last days. As I'm sure many of my fellow students have found, this often does work out in many courses, even in some programming courses, however as we learned doing this project; the larger the project, the more that can go wrong.
For this blog post I'm going to first talk about what my partner and I actually did throughout the project, followed by a contemplation of what I have taken away from the project and will hopefully put into practice in the following iterations.
We started working on parts of the project relatively early in order to get it started (which is often one of the hardest parts of any project), as well as to get an idea how long we would need to spend finishing it. The problem we encountered at this stage was not spending enough time working out our implementation fully. We began by writing a few tests and the very basic outline for the loose idea we had based on the code fragments and assignment information given to us. Since at this point we didn't have a concrete outline of our implementation in our minds or on paper, both the tests and the preliminary code were almost entirely worthless. This was not only harmful in the obvious sense of having to rewrite tests and code, but it also gave us a false sense of how much work we had completed and ahead of us.
Things turned around once my partner and I actually got together with time to spare and spent over an hour just thinking about the problem and how we would implement a solution to it. I got a relatively clear, but abstract, outline written up and we finally got to coding properly. At this point the project went very smoothly for a while; we got new test cases and the implementation and its code was easier to write than our incorrect concept we had originally.
It was when we finally got methods completed enough to attempt running our test cases that things went south again. Neither of us had done very much C or C++ coding, so the code we ended up with had quite a few syntax problems. The majority of these syntax problems were simple but somewhat time consuming to fix, requiring a Google search for some example code to use as a guideline. The one problem that was bad enough to prevent us from getting properly testable code in time was an issue with pointers and their baneful segmentation faults.
Both my partner and I took the Computer Programming II course last semester, which used Java for all of the coding. Java, of course, doesn't use pointers at all, and as such our improper usage and underlying understanding of pointers caused these run-stopping segmentation faults.
This is the point at which the first issue I mentioned caused the most trouble; procrastination. At this point in time, it was the day the project was due, and nothing we tried could fix the segmentation fault. We went through to verify that our code was stylistically sound and tagged it as it was, with hundreds of lines of code un-runnable due to a simple error we just couldn't track down in time.
I've learned a few important things from doing this assignment. For one thing, procrastination with programming assignments is dangerous business, particularly when your concept of the final product isn't fully developed. For future projects like this, spending the hour or two just thinking and talking about the problem and solution to it, as well as writing out a workable outline, will be a non-optional step to be done very early on. Once we had that clear outline, everything else (except for the bad coding) went smoothly and quickly, and that is certainly something to strive for in the future.
Another important lesson was that of early debugging. Increasing or altering features isn't hard to do after you have non-buggy, runnable code. Getting to there is the hardest part, and can be critical if the process involves difficult and time-consuming fixing throughout. Of particular note is that errors that come up earlier allow time to get outside assistance in solving them. Had we run into the pointer issue a day or two earlier we would have had time to ask a TA or peer why that line of code was giving a segmentation fault and how to fix it.
It seems even the issues not directly related to procrastination could have been mitigated by getting to them earlier in the process. For future iterations we will try to both get a concrete understanding as well as a code foundation earlier, leaving time for unexpected problems and reducing likelihood of them in the first place.