COMS W4156

You begin with a mini-project that acts as onboarding for the team project. It’s split into three sprints, and each sprint teaches a technique you’ll later need in the larger project (e.g., setting up GitHub Actions to run unit tests automatically on pushes). This portion felt very manageable—generally under 10 hours/week. The team project is the main time commitment. You build a service in a group of four, essentially implementing a set of endpoints that could support different applications. The project is time-consuming largely because testing is emphasized heavily: you’re given detailed rubrics each sprint (e.g., test each function with typical, edge-case, and invalid inputs), and you’re expected to build comprehensive coverage. Team selection matters a lot—if your group isn’t reliable, the workload can balloon quickly. Also, don’t leave sprints until the last minute; you will almost certainly have rubric questions, and getting clarifications early saves you a ton of stress. A major positive is the mentoring structure. You’re assigned a mentor who provides guidance and clarifies deliverables, and they also grade your work—so staying in communication helps ensure you’re aligned with expectations. My biggest advice: keep the scope small. The more complex your service, the more you’ll have to test, and complexity doesn’t necessarily translate to a better grade. If you plan for…

Workload was average for a core class, but a lot of that effort and time went into seeking out the gotchas that would screw us over in the grading process.

This has been one of my favorite CS classes at Columbia. What I appreciated most is how practically applicable the material is: the techniques map closely to what you’ll encounter in a typical SWE internship, but with a more formal, disciplined framework. For example, most internships will teach you to write unit tests to validate basic functionality. What you likely won’t get on the job—and what this class does especially well—is a structured way to reason about test quality using concepts like equivalence partitioning. The delivery is also excellent. Professor Kaiser explains concepts carefully and at a pace that makes the material genuinely digestible. I consistently felt like I knew what was going on, and the slower pacing gave me time to think critically and ask meaningful questions. I also really liked the interactive portions of lecture, where the class would reason through code snippets together and identify issues. Another thing I appreciated: when students asked questions about material that wasn’t planned for that day, Professor Kaiser would often take note and come back to address it in a later lecture. That’s going above and beyond, and it showed real care for students’ learning experience.

Figuring out exactly what was expected from each assignment and project milestone was the main problem. It seemed like the emphasis wasn't on the software engineering process, but on satisfying very vague and irrelevant conditions as well as pleasing your TA overlords (many of which were visibly on a power trip). Having requirements and even definitions change on you after the fact is incredibly frustrating (euphemism: "clarified"). Lectures usually covered painfully obvious ideas. Also... if you're going to illustrate a nifty connection between refactoring source code and factoring a polynomial, at least factor a middle school problem correctly? Swap wrote x^2 - 2x + 1 on the board and factored it as (x-2)*(x+1). Then he looked at it again and changed it to (x+2)*(x+1) ........................ Yep, this guy occupied a chunk of my semester. -_- Consider the following: http://www.youtube.com/watch?v=oKdYRjwc8T0 skip to 1:10 for the good stuff.

The individual project and group project are split into 3 iterations. The individual project is worth 30%, the group project 50%. Individual assessments let team members allot points to other team members based on perceived contributions, so the grading seems a bit more fair assuming everyone agrees on who did work and who didn't. There were issues with our team grade that the TA seemed to ignore or only reluctantly try to fix, which was annoying, and the "contribution" aspect of the grade (posting on Ed) seemed kind of pointless. If all team members make incremental contributions to each iteration, the workload is very much manageable. If you get stuck with lazy students on your team, workload is going to be a lot more intense.

The course was all online, which seemed fine to start but midway through the semester became frustrating. Most of the Zoom sessions consist of TA demos, some of which were helpful, others not so much. The bulk of the grade is the team project, which comes after an individual project. The individual project teaches you about GitHub workflows, unit testing, etc. and was very helpful. The group project is developing a functional API, which was also a very interesting undertaking. Unfortunately, half of my team members basically did no work and waited until the last second to make only minor contributions, so the team aspect of it seemed useless. However, I learned so much working on the API, it's hard to find much negative to say about the course.

The below reviews would have given a very clear idea about the course and how it was taught ...what is baffling is the fact that the course is a core requirement for MS students when anyone who has worked in the software industry or done an undergraduate in CS would already have done everything that is a part of the course ..The assignments defy all sense of logic ranging from "reading articles " and writing summaries to what seemed to be an experiment on the social behavior of individuals when they are made to test each other's projects..what followed was pretty disappointing and sickening to an extent when teams tried to raise defects in order to gain points...the grading rubric at any point was not concise ..the teaching assistants did try to keep up pace with all the chaos that was going through ...I would not comment if this was still better than what was being taught by the previous but this has to be the most stupid course I have ever had to take as a student

Not recommended. Prof not nice. Didn't learn much things. Very poor experience with Zoom lectures. Time wasted on toy projects. Didn't see the point of having exams, though in the format of take-home assessments.

A lot of vocabulary and writing about common sense concepts. Fun! You also have a semester-long programming project that is graded primarily on l33tness as opposed to actual software engineering concepts.

Whoever took this class with Shirish as TA onboard knows what I mean. Shirish shouldn't be a head TA at all, he controlled your grade and would not care for students and Gail was too busy to do any grading at all. Several students argued with Shirish many times and his condescending attitude pissed everyone off. Overall a class with good content but the assignments were too easy(Shirish made it harder by giving low grades). When Shirish onboard, jump off!