Part of the cheat sheet that I would’ve used for the final, had we been allowed one.
This term I took two courses: Algorithms and Software Engineering I. This post summarizes my experiences with the latter, and offers some advice for people taking the class in the future.
Instructor
Terry Rooker
Topics
Each week of the course focused on a particular topic. Here they are, (more or less) in order:
- Waterfall and Spiral Models
- Requirements
- Diagrams and Notations
- Object-Oriented Design
- Design Patterns
- Agile Model
- Testing and Refactoring
Preparation
Unlike in previous terms, I didn’t prepare for this class in the weeks before it started. This ended up not being a problem.
Programming Environment
This course didn’t put much emphasis on programming, and when it did, it was highly dependent on each group’s particular project.
My group wrote a web app using JavaScript, Node, Express, and Handlebars, and of course CSS and HTML. For pair programming we used CodeAnywhere, which I found cumbersome and buggy. For a “production” environment we used Oregon State’s FLIP server.
Assignments
There were a few individual assignments in this course, but the lion’s share was group work. I’ll discuss the individual work first, then the group work, and then finally, the grading.
The individual work in the class was centered around preparing a vision statement for a product or service. The product was supposed to be something that has some sort of impact on the world and was large enough in scale that a group of undergraduate students wouldn’t be able to implement it in a few weeks. My idea was for an app that would allow people from different cultural, economic, or religious backgrounds to meet and form relationships.
The vision statement itself was broken up into a draft version (due in the first few weeks) and a final version (due toward the end of the term), but don’t let that fool you into thinking that the “draft” version can be anything less than perfect. Based on my experience and the experiences of others who I heard from, this draft version was graded as if it were a final version, so make sure that you’re following the requirements perfectly. To give you an example, I lost a point for not using the correct format to cite my sources. Like I said, treat it like a final version!
The final draft was essentially a structured essay on the idea, technological structure, use cases, target demographic, etc. Mine clocked in at well over 2,000 words (about the same length as this blog post), which might give you a sense of the scale. Speaking of which, this course was heavy on writing, so make sure you’re ready to sit down and type.
All students in the course vote on the draft versions and decide which should be implemented by students in the course. Not fully-implemented, mind you, but at least partially so. My vision statement was chosen, which meant that I had to serve as a “customer” to another group. This required sitting in on a few meetings and reviewing a few documents. In return, I received some extra credit. I’d guess that I spent an additional two or three hours serving as a customer over the course of the term.
As I said, group work made up the majority of the assigned work in the course. This was broken up into seven assignments, each of which required putting together a large document in which we discussed our design, wrote out requirements, and so on. The last two assignments involved actual coding, but the format was open-ended enough that this wasn’t too difficult.
The only significant challenge I faced with my group was differing schedules. I prefer to work early in the morning and early in the week. Ideally, I have all of my homework for the week wrapped up by Friday so that I can spend the weekend hanging out with my wife and daughter. In contrast, most of the rest of my group preferred to work later in the week. This meant that I often ended up working on homework every day of the week. That may be normal for some people, but for me it was a drag. In retrospect, I ought to have just said that I don’t do any work on the weekends and then put in more effort during the weeks to make up for it.
From a pedagogical perspective, I wish that the group work had been structured differently. The way it was set up made for a boring course, which is a cardinal sin in education. People learn better when they’re engaged!
Here are a few of my criticisms: Everyone is randomly assigned to a group and then stuck with that group for the entire course. I had a decent group, but I know plenty of people who didn’t. It’d be better if groups were either shuffled around, or chosen by the students themselves. Even just taking a few weeks off from the group work would’ve been nice (we did have one week off to finish up our vision statements). I understand that the course is specifically about how to work together to build software, but surely there are ways to do that while still keeping the course fresh and engaging. Second, I felt that the groups were too large. The more people in a group the harder it is to divide work evenly, the harder it is to schedule work, and the less ownership each individual person has of the project. Two people make for a great group - five is too many. Third, the projects that we spent the entire term flushing out were also randomly assigned. I know that I would’ve been more engaged with the material if I’d had a say in what I was working on.
Even as I type this, I can hear the instructor in my head arguing counter-points: You don’t always get to choose your teammates! You don’t always get to choose what you work on! Fair enough. But this is school, not work. If breaking the rules and setting up a less than perfectly realistic scenario keeps students engaged, then I’m all for it.
As for grading, there was a running joke among me and others who took the course that it was impossible to receive full credit on an assignment. We received several assignments back with a score of 48/50 and a single comment: “great job!”. Apparently not great enough.
I questioned our TA about the grading early on in the course, and his response was essentially that in order to receive full credit you have to meet all of the requirements and then “do something that no one asked you to do.” I understand the sentiment that you want to encourage students to “go above and beyond,” but when points are deducted without concrete explanation about what can be improved in the future, it’s very frustrating.
Exams
The only examination that took place in this course was the final. I wouldn’t say that I love tests, but I wish there were more opportunities for measuring acquisition of the material. Not only would it give students a better sense earlier on how they were doing, but testing is one of the best ways to learn new things and keep from forgetting. That’s the whole idea behind flashcards as a learning tool, and the reason why you often times don’t fully understand a concept until you have to explain it on an exam.
To be honest, I felt like the acquisition of knowledge was not emphasized in this course. This could’ve been fixed by having weekly auto-graded quizzes, or at the very least a midterm. Again, I don’t love tests, but this small change would go a long way in reorienting the priorities of the course.
Okay, back to the final. It was a drag. I’ll get to why in a moment, but first, this was my study strategy:
- Review each week’s lecture slides
- Keep handwritten notes of important terms and concepts
I tried to break this up over the course of the week so that each day I was reviewing about a week’s worth of slides. This kept me from cramming and gave plenty of time for the material to solidify.
I ended up earning a 53/70 on the final, which is a pretty mediocre grade, so you may want to take my basic study strategy with a grain of salt. Perhaps it would’ve been helpful to watch the lectures in addition to viewing the slides, but this would’ve required much, much more time. As I was also studying for two other (arguably more difficult) finals, this was a luxury I couldn’t afford.
Even so, I’m not sure that studying more would’ve had much of an impact on my grade. The reason has to do with a common refrain throughout the course: “It depends.”
As with most questions in life, the answer to many questions and conundrums that pop up in this course is “It depends.” And indeed it does! Which should you choose: Agile or Waterfall? It depends. UML or ER diagrams? It depends. Factory design pattern or builder? It depends.
To his credit, Mr. Rooker is up-front about this fact and doesn’t shy away from the subjective nature of the material. The problem though is that the final is written as if this weren’t the case. Rather than posing questions which are inherently subjective and then giving students the opportunity to answer and explain their reasoning in a text-entry field, the final was solely comprised of true or false and multiple choice questions. And no, none of the choices were “It depends.”
I can’t reprint any of the questions here, of course, but for the sake of argument, here’s an example: “You’re driving across the country and want to minimize your costs. The best type of automobile is a sedan. True or false?” Of course this depends on a variety of factors (how many people, how much stuff, season, etc.), so to only have the choice of true or false was frustrating. To me, the solution is straightforward: pick the objective ideas and turn them into multiple choice questions. Anything that might be answered with “It depends!” gets a text-entry field. Yes, it’ll take more time to grade. But it’ll also be a better reflection of a student’s knowledge and impart less resentment to boot.
Another frustrating part of the test was that multiple questions were repeated, word for word. In that case, what’s the best strategy? Give different answers to cancel the duplicate questions out? Double down on whatever you think is right? Needless to say, these aren’t the sorts of things you want to be thinking about during a final. Obviously everyone, including instructors, make mistakes, but I feel like something like this, on a final, is inexcusable.
Extra Resources
On the whole, I felt like Mr. Rooker did a good job of explaining the course material. As such, I never felt the need to look to other resources.
Difficulty and Time Commitment
The material presented in this course is not difficult to understand, nor is the workload heavy. That said, I found it to be the most stressful course I took this term for reasons outlined above (group work, grading, and the final), and by far the most frustrating in the program.
In total I spent about 84 hours on this course, which works out to about 8.4 hours per week. To put that in perspective, I spent about 12 hours per week on Algorithms (which I also took this term), 9 hours per week on Web Development, and 9 hours per week on Databases. Unfortunately I don’t have accurate data for the courses I took before that. Note that this is focused, “nose-in-the-book” study time. I didn’t count the time I spent getting up and going to the bathroom, eating lunch, daydreaming, etc.
For what it’s worth, I took two other courses this term (Algorithms here at Oregon State and Calculus III at Portland Community College). I also take care of my one-year-old daughter (along with my wife and in-laws) and volunteer one afternoon per week at a local high school teaching computer science.