OSU eCampus CS361 Software Engineering I review & recap

This post is part of an ongoing series recapping my experience in Oregon State University’s eCampus (online) post-baccalaureate Computer Science degree program. You can learn more about the program here.

Six-word summary: Group work group work group work

In CS361 you’ll get a high level look at “real world” scheduling methodologies (mostly waterfall and agile) and you’ll work in a group with 3-4 other students to meet weekly milestones designing and implementing parts of some other student’s “Vision Statement”.

CS361 Review

You don’t have to spend long on the OSU CS subreddit to realize that virtually no one likes this class. It’s not awful, but I understand the frustrations people voice on various forums around the web.

The heavy reliance on group work was frustrating more often than not and the course materials felt dated or like they were specific to a certain industry, but I didn’t dislike this class as much as most people seem to. I think it helped that I already have design and software development experience and enjoy writing and making diagrams/mockups, so this class played to some of my strengths.

The materials that introduce common planning and scheduling techniques for software projects were a welcome inclusion – I’m glad this stuff is covered somewhere in OSU’s CS program – but I thought they didn’t go nearly in depth enough to prepare students for the realities of working on an agile team. There wasn’t enough story writing, requirements gathering, pointing exercises, or customer involvement.

I thought the weekly homework assignments were a little lackluster. Working in a group is tough even in the best situations – some parts of the homework depended on other parts being done first, and some people’s schedules didn’t seem to allow for them to start the homework early in the week.

The documents we wrote as a group seemed excessively heavy on diagrams and put too much emphasis on satisfying a very specific set of expectations. For example, there’s a lot of emphasis placed on terminology such as “functional requirements” and “functional definitions”, which I had never heard outside of this class or seen used so religiously, but the concepts they represent were familiar. That describes a lot of this class’s materials: heavy focus on overly-specific methods and terms that probably don’t translate to every industry.

Maybe the course’s materials would be improved by taking a step back from strict terminology and definitions and talking instead about how to write good step-by-step documentation, how to write a good bug, how to write a good feature design that someone else can implement from – skills that can be applied to a variety of specific methodologies, since it’s impossible to predict which ones your future company or team might be using. There are so many skills that have nothing to do with programming that programmers still need to develop, and this class could be a good place to start learning them.

Class structure

• In the first week of the class, everyone in the class writes a 2000 word “Vision Statement” for a software product that solves some lofty real-world problem. Forget about making a simple app to solve a simple problem, your idea for this vision statement should be utterly epic. They are surprisingly strict about the 2000 word count, but you should be able to hit that easily by showing off your design skills and covering every topic imaginable in relation to your app idea. You really can’t write too much, and no topic is too trivial to not write a page about. (I thought I’d covered security pretty well with the half page I wrote on it, but I got got dinged for not writing enough on the topic. I got the feeling the TA had to find something wrong with my document and if it wasn’t that, it’d have been something else.)
• In the second week of the class, everyone votes on which ideas they think are best.
• It doesn’t matter what you vote for. Your voting has no bearing on what project you get assigned. But you should vote anyway to help lift decent-sounding projects to the top, so that nobody has to work on the duds.
• Expect to be assigned to a project you didn’t vote for because you thought it sounded stupid or impossible (or both).
• You’ll then get grouped with 3-4 classmates based on absolutely no criteria whatsoever, so expect clashing schedules/mismatched interests/time zone incompatibilities. The instructor says this is part of life, and I agree (and every single software team I’ve been on has had an off-shore counterpart on the other side of the globe), but don’t expect your teammates to be so understanding. My group insisted that the only time we could meet was what was usually my bedtime, which sucked for me.
• You’ll get to know these people very well as you meet 1-2 times a week (probably over a voice chat if your group is keyboard-phobic or generally unavailable at any time of day outside of the specific meeting window)
• Every week you’ll work with these people to produce a lengthy document in response to a lengthy prompt. It will require diagrams and lots and lots of writing.
• This assignment will be graded by a TA who might have limited English skills or a general lack of interest in reading 12+ pages of rather dry writing. We lost points on things that were present and the TA missed and we lost points on things that were never part of the requirements in the first place.
• The last two weeks of the term are spent coding a small portion of the stuff you designed thus far; your group members may or may not participate in this process depending on whether they’re dirtbags or not
• The final is made up of rather vague questions, but you should review the slides anyway to scoop up whatever points you can here

CS361 Tips

Vision statement tips

The grading requirements on the vision statement draft are really vague, but you can get full credit by writing a ton on every design topic you can think of and meeting the 2000 minimum word requirement.

Some ideas of what to include (beyond what the assignment suggests):

• What differentiates your app from similar ones – do some market research and write comparisons. Someone’s probably already made a product like the one you’re imagining. What makes yours better? 
• User profiles – Imagine some hypothetical users for your app and write about them. Are they young? Old? Tech-savvy? Tech-illiterate? How is your app designed to appeal to them and meet their needs?
• Accessibility features – imagine how your app might work on a screen reader or to someone with limited vision and write about how accessibility concerns are addressed in your app.
• Security features – I wrote like half a page on security, which wasn’t enough according to my TA. Maybe you can do better!
• Mockups! I made mine in mockflow

Journal tips

Work on the journal regularly – every other day is a good pace. The class’s instructor looks at these himself (or at least he looked at mine himself and commented on it) and he’s very good at detecting who wrote theirs in one fell swoop the night before it was due.

If you don’t know what to write, here are some ideas I used throughout the course to inspire myself:

• Draw a comparison between the class’s material and your experiences working in a team – you ought to have some from your previous career or OSU classes
• Talk about any previous software development experience you have; maybe throw in a bit about how you think CS361’s teachings on topics like agile will help you on future projects you develop
• Talk about how your group work is going
• Relate the lecture material to outside reading you’ve done or things you’ve heard
• Sometimes the lecturer asks questions in the video; respond to those
• Respond to the weekly learning topics: early in the week, write what you think they mean, then, after you do the lectures and your part of the homework, write again about what you’ve learned about those topics and correct any misinterpretations you had initially

Track your group members’ contributions

Yes, it feels creepy to keep secret notes about who in your group isn’t attending meetings, who turned in their part just hours before it was due, etc., but in the last week you’ll be asked to produce a very long, very detailed document rating each group member on a half-dozen criteria and justifying your rating in writing, so having kept track of this stuff will help you earn full credit on the assignment. I did my group member tracking in a Google Spreadsheet with a column for each week of the class and a row for each group member.

A lot of people in the Slack channel reported getting dinged for not being detailed enough, so keep regular notes and you should have plenty of material for this document and you should be able to write it in very little time. (Mine was 14 pages and included screenshots and data about meeting attendance and how close to the weekly deadline each person submitted their work; I got full credit on the group evaluation.)

Pick a programming language / framework that plays to your group’s strengths

Three people in my group inexplicably voted in favor of a framework they had little to no familiarity with – and majority ruled. I spent 2 weeks giving myself a crash course in JavaFX, coding as I went, which was fine but our development weeks would have gone so much better if the group had just picked something we already knew and could’ve hit the ground running in. The end result: some group members struggled to produce anything at all during the coding weeks.

Here’s what we ended up with: a clickable map of the United States that colors states according to how they voted in the 2016 presidential election and, alternatively, according to how gerrymandered they are.

This screenshot best represents my portion of the work: building the map and hooking it up to real data.

Implementing this much functionality posed plenty of interesting challenges to work through. Things like building a complete map out of individual SVG boundaries, figuring out how to make them clickable, altering their color based on data from the project’s database, and fitting containers within containers to get everything fitting in the application window kept me busy for the two weeks.

For some people in my group this was their first exposure to Git as well, so this project came with a side-helping of Git training. (Note to any future students out there: if you don’t know git yet, start learning it now – don’t wait until you’re in a time crunch of a group project with multiple people counting on you.)

And finally…

Don’t be a dick

Show up to meetings. Do your part and do it early enough so that your group can review it. Don’t disappear during the coding weeks. Be a good team member and make connections on LinkedIn once the class is over.

An educational program like this one is a huge opportunity to network and make friends; you never know who might end up at a great company someday and put in a good word for you. You can gripe about 361 and sandbag for two months, or you can impress a bunch of future industry peers by knocking it out of the park every week.

It’s only 10 weeks – you can do it!