This term I took three courses: Operating Systems and Software Engineering II at Oregon State, and Linear Algebra at Portland Community College. This post summarizes my experience with Software Engineering II, and offers some advice for people taking the class in the future.
Instructor
Jaki Sharief Shaik
Topics
This course covers two main topics: version control and testing. It breaks those topics up into the following sections:
- Git and GitHub
- Unit and integration testing
- Random testing
- Code coverage
- Debugging
Preparation
Earlier in the program I used to spend the weeks leading up to a new term preparing for the material I would soon be learning. And I’m not the only one – it’s not uncommon to see folks asking on Slack what they can do to prepare for an upcoming class.
I actually had a week between when my internship ended and when this term began, and so I could’ve spent a week learning Vim, or polishing my testing and version control skills, or even doing some advance learning for linear algebra. But I didn’t do any of those things.
Instead, I took a road trip with my wife and daughter to the Alvord Desert in Southeastern Oregon. And that’s the advice I’d give you, too. Take a break! Let school be about school and your breaks be about taking a break.
All of that said, I think that I was already reasonably prepared for the practical aspect of the material covered in this course. I’ve been using git and GitHub for several years, I’ve used several testing frameworks in C++ (Catch2 and Google Test), and I did a ton of testing and debugging during my internship at Insitu. And as you’d expect, that work was versioned, though not through git or GitHub.
Programming Environment
I did most of my coding locally through VS Code (which is fantastic). I also tested some (though not all) of my code on Oregon State’s FLIP server.
None of the coding or debugging in this course was particularly intense, so I never felt like the extra power of an IDE was necessary.
Assignments
There were several individual assignments plus a group assignment:
- Assignment 1: Fork the class repository and study Dominion codebase
- Assignment 2: Refactor Dominion code and introduce bugs
- Assignment 3: Write unit tests for Dominion code
- Assignment 4: Write a random tester
- Assignment 5: Test a classmate’s code with your tests
- Random Testing Quiz: Implement a random tester (more like an assignment, not connected to Dominion)
- Group Assignment Part A: Review existing test cases for a URL validator written in Java
- Group Assignment Part B: Add to existing test suite from Part A
I found most of these assignments to be a drag. The Dominion codebase was large and disorganized, which was only compounded by the fact that we were introducing our own arbitrary changes and bugs. I’d much rather have had a smaller codebase since we were essentially learning from first principles.
While the entire course was ostensibly version-controlled (since we started by forking a repository and were expected to commit our changes for each assignment), I wished that version control had been a much larger part of the course.
I think that testing is relatively easy to develop intuition about since we’re constantly testing things in our daily lives (“Does the switch turn on the light?”). Version control, on the other hand, is something we don’t really do in our daily lives, let alone manually managing it and keeping it in sync with other people. As a case in point, I used to think that I understood version control, and then I tried to open a pull request against an open source project. I still had a lot to learn.
However, there were a few assignments I liked about this course, like the random testing quiz (which was really more of an assignment).
One thing I liked about this assignment was that it’s scope was much more manageable. It didn’t have anything to do with Dominion, so our work wasn’t predicated on understanding the inner workings of Dominion’s code. This made me realize that one of the reasons I got bored of the class was that we were working with the same Dominion code over and over. It would’ve been nice to mix things up a bit.
The other thing I liked was that we had a clear objective, which was to implement a random tester that successfully met all test cases in less than five minutes. For many of the Dominion assignments, in comparison, the tasks we were directed to complete were much more open-ended. Sometimes it’s nice to have clear directives and to know when your work is done.
As with all group work, it depends on who you end up with. I worked with a few friends with whom I’d worked in the past, so this part wasn’t too painful. What was painful, however, was following the instructor’s directions for getting Java and JUnit up and running (if you end up in this situation, do yourself a favor and follow a different guide).
Why you would teach the entire course in C and then pivot to Java and JUnit right at the end was beyond me. Much better to pick a language and testing suite (like C++ and Catch2) and stick with it for the entire course.
Exams
The midterm and the final were both unproctored. I like not having to pay proctoring fees, but I also know that I don’t study as much for unproctored exams, nor do I take them as seriously. I didn’t study for either of the exams in this course and I did fine on both of them.
The midterm involved answering open-ended questions and writing code, and the final was multiple-choice questions in Canvas. I saw some people complaining about the questions in the final, but I didn’t find any of them to be overly confusing or unfair. And anyway, so much of the course was so easy that I didn’t think any of us had room to complain.
Extra Resources
I didn’t use any extra resources for this course, but here are some links I’ve saved related to version control:
General Strategy
I’ll be the first to admit that I had a hard time getting excited about this course. As I said above, I was familiar with a lot of the topics already, and I felt like the course didn’t expand my understanding. In some cases, I found the material to be a step back from what I’d learned on my own. This feeling of meh-ness was compounded by the fact that a lot of the assignments were almost trivially easy. There was a running joke on Slack during the term that any submission, regardless of mediocre, would receive a 100 percent.
Taking all of the above into account, my general strategy would be to be different than me. Even if the class is a drag, take it seriously! The material (version control and testing) is extremely important, and a lot of the lectures are actually quite good (even if you have to put up with the lecturer reminding you over and over that he used to work at NASA).
Difficulty and Time Commitment
This course was easy, possibly the easiest in the program. I spent about 35 hours on this course, which works out to about 3.5 hours per week. This number may seem very low, but I keep pretty careful track of my time and so I think that it’s accurate. Like I said, it was easy.
To put this in perspective, I spent about 8 hours per week on Software Engineering I, 9 hours per week on Databases, and 9 hours per week on Web Development. Note that this is focused, “nose-in-the-book” study time. I didn’t count the time I spent going to the bathroom, eating lunch, daydreaming, etc.
I took two other courses this term (Operating Systems at Oregon State and Linear Algebra at Portland Community College). I also take care of my two-year-old daughter (along with my wife and in-laws) and volunteer one afternoon per week at a local high school teaching computer science.
Enjoyment and Ideas for Changes
As I’ve said above, this course was a drag. Not because it was overly difficult, or disorganized, or frustrating. I just didn’t feel like I learned much, and I never really felt challenged (a key ingredient of growth).
There were a lot of things that I wish were different about this course. If I were king of the world (or at least king of this course) here are some changes I’d implement:
- Start using a testing framework from week one or two
- Use a testing framework that’s easy to set up (like Catch2)
- Spend more than a week on version control
- Cover pull requests
- Cover .gitignore files
- Require students to merge their code together
- Do more assignments like the random testing quiz
One thing that got me fired up about testing when I first started to learn it was that it gives you a way of showing that whatever you wrote actually works. If I built a chair out of wood but never sat in it, how sure could I be that I’d done good work? Similarly, if we’re not rigorously testing our code, then how do we know what we’re really doing?
Unfortunately, this class lacked that fire. Since we were testing code that had already been written, I didn’t really have a stake in whether or not it was any good. I wish that I had.
Alternatively, if we were given a program and explicitly told that there were three bugs and that we had to design a test suite to catch all three, that would’ve set me on the case to prove someone else’s code wrong (which could be even more fun!). Having everything open-ended, wherein we’re introducing our own bugs, or trying to track down an unknown number of existing bugs that may or may not exist, is much less fun. It might better mirror the real world, but this is school, not the real world, and if we can make it fun, we should.